Hi Jerin, > > > > > > > > [...] > > > > > > + > > > > +#ifdef RTE_ETHDEV_TX_PREP > > > > > > Sorry for being a bit late on that discussion, but what the point of > > > having that config macro (RTE_ETHDEV_TX_PREP ) at all? > > > As I can see right now, if driver doesn't setup tx_pkt_prep, then > > > nb_pkts would be return anyway... > > > > > > BTW, there is my another question - should it be that way? > > > Shouldn't we return 0 (and set rte_errno=ENOTSUP) here if > > > dev->tx_pk_prep == NULL? > > > > > > > It's an answer to the Jerin's request discussed here: > > http://dpdk.org/ml/archives/dev/2016-September/046437.html > > > > When driver doesn't support tx_prep, default behavior is "we don't know > > requirements, so we have nothing to do here". It will simplify > application logic and improve performance for these drivers, I think. > Catching this error with every burst may be problematic. > > > > As for RTE_ETHDEV_TX_PREP macro, suggested by Jerin in the same thread, I > > still don't think It's the best solution of the problem > described by him. I have added it here for further discussion. > > > > Jerin, have you something to add? > > Nothing very specific to add here. I think, I have tried to share the > rational in, http://dpdk.org/ml/archives/dev/2016- > September/046437.html >
Ok, not sure I am fully understand your intention here. I think I understand why you propose rte_eth_tx_prep() to do: if (!dev->tx_pkt_prep) return nb_pkts; That allows drivers to NOOP the tx_prep functionality without paying the price for callback invocation. What I don't understand, why with that in place we also need a NOOP for the whole rte_eth_tx_prep(): +static inline uint16_t +rte_eth_tx_prep(uint8_t port_id __rte_unused, uint16_t queue_id __rte_unused, + struct rte_mbuf **tx_pkts __rte_unused, uint16_t nb_pkts) +{ + return nb_pkts; +} + +#endif What are you trying to save here: just reading ' dev->tx_pkt_prep'? If so, then it seems not that performance critical for me. Something else? >From my point of view NOOP on the driver level is more than enough. Again I would prefer to introduce new config option, if possible. Konstantin