Re: [dpdk-dev] Rx/Tx offloads checks behaviour in 18.05

[Shahaf Shuler <shahafs@mellanox.com>]

Monday, May 14, 2018 1:00 PM, Ferruh Yigit:
> >
> > It depends on which PMD is used. Yes, it was no checks in ethdev before.
> > If PMD does not support multi-segment Tx, some checksum or VLAN
> > insertion offload, but application requests it and rely on it, it will
> > result in invalid packets sent to network.
> >
> > I realize that some applications may simply use empty txq_flags, but
> > do not use any offloads in fact. If so, such PMDs will fail to setup
> > TxQ if checks are made fatal, return error and underlying PMD does not
> >  support these offloads.
> >
> > At least it is safer behaviour than transmitting garbage.
> > Yes, not easy decision.
> >
> > I will publish my patches which passed our tests.
> >
> >
> >
> > I agree with Andrew here. Even though there is a concern about the
> > existing application we cannot use only logging.
> >
> > It is better to enforce the right behavior rather than having wrong
> > configuration silently accepted by the PMD.
> 
> What do you think send an error for the application that switch to new
> offloading API and only print error log for the old ones. I believe we can
> detect this via ETH_TXQ_FLAGS_IGNORE and ignore_offload_bitfield.
> 
> And we will already force old applications to switch to new API next release,
> next release we can introduce return error without condition.
> Does it make sense?

The issue is currently none of the PMDs verify the offloads v.s. the caps as ethdev layer does it. 
We cannot have offload to be set if it is not supported, even under the old API. allowing such breach on ethdev means we need to enforce it back again on each PMD.