DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Rao, Nikhil" <nikhil.rao@intel.com>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: Nipun Gupta <nipun.gupta@nxp.com>,
	Jerin Jacob <jerinj@marvell.com>, dpdk-dev <dev@dpdk.org>,
	Pavan Nikhilesh <pbhagavatula@marvell.com>,
	"Sunil Kumar Kori" <skori@marvell.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"Kovacevic, Marko" <marko.kovacevic@intel.com>,
	 Ori Kam <orika@mellanox.com>,
	"Nicolau, Radu" <radu.nicolau@intel.com>,
	"Kantecki, Tomasz" <tomasz.kantecki@intel.com>,
	"Van Haaren, Harry" <harry.van.haaren@intel.com>,
	Hemant Agrawal <hemant.agrawal@nxp.com>
Subject: Re: [dpdk-dev] [PATCH] eventdev: flag to identify same destined packets enqueue
Date: Tue, 22 Oct 2019 09:42:07 +0000	[thread overview]
Message-ID: <1F668163772FA946975B9466A9DFF729EDEEE736@ORSMSX122.amr.corp.intel.com> (raw)
In-Reply-To: <CALBAE1PRsaQNLvmnXP1a-rkMcK2a08xdwd9ou9ta2WLSDsp=Tw@mail.gmail.com>


> -----Original Message-----
> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> Sent: Tuesday, October 22, 2019 2:15 PM
> To: Rao, Nikhil <nikhil.rao@intel.com>
> Cc: Nipun Gupta <nipun.gupta@nxp.com>; Jerin Jacob <jerinj@marvell.com>;
> dpdk-dev <dev@dpdk.org>; Pavan Nikhilesh <pbhagavatula@marvell.com>;
> Sunil Kumar Kori <skori@marvell.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; Kovacevic, Marko
> <marko.kovacevic@intel.com>; Ori Kam <orika@mellanox.com>; Nicolau, Radu
> <radu.nicolau@intel.com>; Kantecki, Tomasz <tomasz.kantecki@intel.com>;
> Van Haaren, Harry <harry.van.haaren@intel.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>
> Subject: Re: [dpdk-dev] [PATCH] eventdev: flag to identify same destined
> packets enqueue
> 
> On Mon, Oct 21, 2019 at 5:05 PM Rao, Nikhil <nikhil.rao@intel.com> wrote:
> >
> > > -----Original Message-----
> > > From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> > > Sent: Thursday, October 3, 2019 3:57 PM
> > > To: Hemant Agrawal <hemant.agrawal@nxp.com>
> > > Cc: Rao, Nikhil <nikhil.rao@intel.com>; Nipun Gupta
> > > <nipun.gupta@nxp.com>; Jerin Jacob <jerinj@marvell.com>; dpdk-dev
> > > <dev@dpdk.org>; Pavan Nikhilesh <pbhagavatula@marvell.com>; Sunil
> > > Kumar Kori <skori@marvell.com>; Richardson, Bruce
> > > <bruce.richardson@intel.com>; Kovacevic, Marko
> > > <marko.kovacevic@intel.com>; Ori Kam <orika@mellanox.com>; Nicolau,
> > > Radu <radu.nicolau@intel.com>; Kantecki, Tomasz
> > > <tomasz.kantecki@intel.com>; Van Haaren, Harry
> > > <harry.van.haaren@intel.com>
> > > Subject: Re: [dpdk-dev] [PATCH] eventdev: flag to identify same
> > > destined packets enqueue
> > >
> > </snip>
> >
> > > > > > But I am not able to recollect, Why Nikhil would like to use
> > > > > > the separate functions. Nikhil could you remind us why
> > > > > > rte_event_eth_tx_adapter_enqueue() can not be used for sending
> > > > > > the packet for SW Tx adapter.
> > > > > >
> > > > > [Nikhil] The goal was to keep the workers using the loop below.
> > > > >
> > > > > while (1) {
> > > > >         rte_event_dequeue_burst(...);
> > > > >         (event processing)
> > > > >         rte_event_enqueue_burst(...); }
> > >
> > > We do have specialized functions for specific enqueue use case like
> > > rte_event_enqueue_new_burst() or
> > > rte_event_enqueue_forward_burst() to avoid any performance impact.
> > >
> > > Since PMD agruments are same for rte_event_enqueue_burst() and
> > > rte_event_eth_tx_adapter_enqueue()
> > > assigning simple function pointer assignment to
> > > rte_event_eth_tx_adapter_enqueue as dev->txa_enqueue =
> > > dev->enqueue_burst
> > > would have worked to have same Tx function across all platfroms
> > > without peformance overhead.
> > > Offcouse I understand, Slow path direct event enqueue assigment
> > > needs different treatment.
> > >
> > >
> > > ie in fastpath.
> > >
> > > while (1) {
> > >        rte_event_dequeue_burst(...);
> > >       if (tx_stage)
> > >         rte_event_eth_tx_adapter_enqueue()...
> > > }
> > >
> > > What do you say?
> > >
> >
> > Sorry missed this question previously - Unless I have misunderstood your
> email, the event processing stage would have if conditions for each of the
> stages (or minimally the tx stage), no disagreement on that, the only difference
> would be set up  of the event[] arrays that are sent to
> rte_event_enqueue_burst() and rte_event_eth_tx_adapter_enqueue() resulting
> in an additional call to rte_event_enqueue_burst(). If that’s true, since the
> abstraction has a cost to it,  should we be adding it ?
> 
> It there is a cost then we should not be adding it.
> I think, the following scheme can avoid the cost by adding the following in a
> _slow path_ as the prototype of the driver API is the same.
> 
> dev->txa_enqueue = dev->enqueue_burst;
> 

I was thinking of the event loop below which results in 2 calls to rte_event_enqueue_burst()

while (1) {
	rte_event_dequeue_burst(...);
	
	for_all_events {
             		if (tx_stage) 
			event_tx[tx_cnt++] = ...
		else 
			event_non_tx[non_tx_cnt++] = ...

	}
	if (tx_cnt)
	             rte_event_eth_tx_adapter_enqueue(event_tx, tx_cnt); 
	if (non_tx_cnt)
		rte_event_enqueue_burst(event_non_tx, non_tx_cnt); 
  }

Thanks,
Nikhil

  reply	other threads:[~2019-10-22  9:42 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-01  6:46 Nipun Gupta
2019-10-01  7:44 ` Jerin Jacob
2019-10-01 11:41   ` Nipun Gupta
2019-10-01 13:09     ` Jerin Jacob
2019-10-01 14:02       ` Nipun Gupta
2019-10-01 14:20         ` Jerin Jacob
2019-10-01 15:06           ` Nipun Gupta
2019-10-01 15:35             ` Jerin Jacob
2019-10-02  3:08               ` Hemant Agrawal
2019-10-02  7:54                 ` Jerin Jacob
2019-10-03  6:12                   ` Rao, Nikhil
2019-10-03  6:45                     ` Hemant Agrawal
2019-10-03 10:26                       ` Jerin Jacob
2019-10-21 11:35                         ` Rao, Nikhil
2019-10-22  8:45                           ` Jerin Jacob
2019-10-22  9:42                             ` Rao, Nikhil [this message]
2019-10-23  4:53                               ` Jerin Jacob
2019-10-01 14:42 ` Aaron Conole
2019-10-01 15:15   ` Nipun Gupta
2019-10-04  6:55 ` [dpdk-dev] [PATCH v2] " Nipun Gupta
2019-10-04  8:21   ` Jerin Jacob
2019-10-04 10:47 ` [dpdk-dev] [PATCH v3] " Nipun Gupta
2019-10-05 16:23   ` Jerin Jacob
2019-10-09  7:32 ` [dpdk-dev] [PATCH v4] " Nipun Gupta
2019-10-10 10:06   ` Rao, Nikhil
2019-10-10 12:43     ` Nipun Gupta
2019-10-11  6:14       ` Jerin Jacob
2019-10-11 13:03 ` [dpdk-dev] [PATCH v5] " Nipun Gupta
2019-10-16  6:41   ` Hemant Agrawal
2019-10-16  7:19   ` Jerin Jacob

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1F668163772FA946975B9466A9DFF729EDEEE736@ORSMSX122.amr.corp.intel.com \
    --to=nikhil.rao@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=harry.van.haaren@intel.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerinj@marvell.com \
    --cc=jerinjacobk@gmail.com \
    --cc=marko.kovacevic@intel.com \
    --cc=nipun.gupta@nxp.com \
    --cc=orika@mellanox.com \
    --cc=pbhagavatula@marvell.com \
    --cc=radu.nicolau@intel.com \
    --cc=skori@marvell.com \
    --cc=tomasz.kantecki@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).