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

Ananyev, Konstantin konstantin.ananyev at intel.com
Tue Nov 1 13:57:17 CET 2016

Hi Thomas,
> > > I suggest to integrate it in the beginning of 17.02 cycle, with the hope
> > > that you can convince other developers to implement it in other drivers,
> > > so we could finally enable it in the default config.
> >
> > Ok, any insights then, how we can convince people to do that?
> You just have to explain clearly what this new feature is bringing
> and what will be the future possibilities.
> > BTW,  it means then that tx_prep() should become part of mandatory API
> > to be implemented by each PMD doing TX offloads, right?
> Right.
> The question is "what means mandatory"?

For me "mandatory" here would mean that:
 - if the PMD supports TX offloads AND
 - if to be able use any of these offloads the upper layer SW would have to:
	- modify the contents of the packet OR
	- obey HW specific restrictions
 then it is a PMD developer responsibility to provide tx_prep() that would implement
 expected modifications of the packet contents and restriction checks.
Otherwise, tx_prep() implementation is not required and can be safely set to NULL.      

Does it sounds good enough to everyone?

> Should we block some patches for non-compliant drivers?

If we agree that it should be a 'mandatory' one - and patch in question breaks
that requirement, then probably yes.

> Should we remove offloads capability from non-compliant drivers?

Do you mean existing PMDs?
Are there any particular right now, that can't work properly with testpmd csumonly mode?



More information about the dev mailing list