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?
Konstantin
