[dpdk-dev] [PATCH v2 1/6] ethdev: add Tx preparation

[Ananyev, Konstantin]

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