Hi Thomas, Sorry, I have answered for this question in another thread and I missed about this one. Detailed answer is below.
> -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] > Sent: Thursday, December 1, 2016 17:24 > To: Kulasek, TomaszX <tomaszx.kula...@intel.com> > Cc: dev@dpdk.org; Ananyev, Konstantin <konstantin.anan...@intel.com>; > olivier.m...@6wind.com; Richardson, Bruce <bruce.richard...@intel.com> > Subject: Re: [dpdk-dev] [PATCH v12 1/6] ethdev: add Tx preparation > > Please, a reply to this question would be greatly appreciated. > > 2016-11-28 11:54, Thomas Monjalon: > > Hi, > > > > 2016-11-23 18:36, Tomasz Kulasek: > > > --- a/config/common_base > > > +++ b/config/common_base > > > @@ -120,6 +120,7 @@ CONFIG_RTE_MAX_QUEUES_PER_PORT=1024 > > > CONFIG_RTE_LIBRTE_IEEE1588=n > > > CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16 > > > CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y > > > +CONFIG_RTE_ETHDEV_TX_PREPARE=y > > > > Please, remind me why is there a configuration here. > > It should be the responsibility of the application to call tx_prepare > > or not. If the application choose to use this new API but it is > > disabled, then the packets won't be prepared and there is no error code: > > > > > +#else > > > + > > > +static inline uint16_t > > > +rte_eth_tx_prepare(__rte_unused uint8_t port_id, __rte_unused > uint16_t queue_id, > > > + __rte_unused struct rte_mbuf **tx_pkts, uint16_t > > > +nb_pkts) { > > > + return nb_pkts; > > > +} > > > + > > > +#endif > > > > So the application is not aware of the issue and it will not use any > > fallback. tx_prepare mechanism can be turned off by compilation flag (as discussed with Jerin in http://dpdk.org/dev/patchwork/patch/15770/) to provide real NOOP functionality (e.g. for low-end CPUs, where even unnecessary memory dereference and check can have significant impact on performance). Jerin observed that on some architectures (e.g. low-end ARM with embedded NIC), just reading and comparing 'dev->tx_pkt_prepare' may cause significant performance drop, so he proposed to introduce this configuration flag to provide real NOOP when tx_prepare functionality is not required, and can be turned on based on the _target_ configuration. For other cases, when this flag is turned on (by default), and tx_prepare is not implemented, functional NOOP is used based on comparison (dev->tx_pkt_prepare == NULL). Tomasz
