On Mon, Oct 21, 2019 at 5:05 PM Rao, Nikhil <nikhil....@intel.com> wrote: > > > -----Original Message----- > > From: Jerin Jacob [mailto:jerinjac...@gmail.com] > > Sent: Thursday, October 3, 2019 3:57 PM > > To: Hemant Agrawal <hemant.agra...@nxp.com> > > Cc: Rao, Nikhil <nikhil....@intel.com>; Nipun Gupta <nipun.gu...@nxp.com>; > > Jerin Jacob <jer...@marvell.com>; dpdk-dev <dev@dpdk.org>; Pavan Nikhilesh > > <pbhagavat...@marvell.com>; Sunil Kumar Kori <sk...@marvell.com>; > > Richardson, Bruce <bruce.richard...@intel.com>; Kovacevic, Marko > > <marko.kovace...@intel.com>; Ori Kam <or...@mellanox.com>; Nicolau, Radu > > <radu.nico...@intel.com>; Kantecki, Tomasz <tomasz.kante...@intel.com>; > > Van Haaren, Harry <harry.van.haa...@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; > > Nikhil
