> -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com] > Sent: Wednesday, July 27, 2016 6:11 PM > To: Thomas Monjalon <thomas.monjalon at 6wind.com> > Cc: Kulasek, TomaszX <tomaszx.kulasek at intel.com>; dev at dpdk.org; > Ananyev, Konstantin <konstantin.ananyev at intel.com> > Subject: Re: [dpdk-dev] [PATCH v2] doc: announce ABI change for rte_eth_dev > structure > > On Wed, Jul 27, 2016 at 01:59:01AM -0700, Thomas Monjalon wrote: > > > > Signed-off-by: Tomasz Kulasek <tomaszx.kulasek at intel.com> > > > > --- > > > > +* In 16.11 ABI changes are plained: the ``rte_eth_dev`` structure > > > > +will be > > > > + extended with new function pointer ``tx_pkt_prep`` allowing > > > > +verification > > > > + and processing of packet burst to meet HW specific requirements > > > > +before > > > > + transmit. Also new fields will be added to the ``rte_eth_desc_lim`` > > > > structure: > > > > + ``nb_seg_max`` and ``nb_mtu_seg_max`` provideing information > > > > +about number of > > > > + segments limit to be transmitted by device for TSO/non-TSO packets. > > > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev at intel.com> > > > > I think I understand you want to split the TX processing: > > 1/ modify/write in mbufs > > 2/ write in HW > > and let application decide: > > - where the TX prep is done (which core) > > In what basics applications knows when and where to call tx_pkt_prep in fast > path. > if all the time it needs to call before tx_burst then the PMD won't > have/don't need this callback waste cycles in fast path.Is this the expected > behavior ? > Anything think it as compile time to make other PMDs wont suffer because of > this change.
Not sure what suffering you are talking about... Current model - i.e. when application does preparations (or doesn't if none is required) on its own and just call tx_burst() would still be there. If the app doesn't want to use tx_prep() by some reason - that still ok, and decision is up to the particular app. Konstantin > > > > - what to do if the TX prep fail > > So adding some processing in this first part becomes "not too > > expensive" or "manageable" from the application point of view. > > > > If I well understand the intent, > > > > Acked-by: Thomas Monjalon <thomas.monjalon at 6wind.com> (except typos ;)
