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

[Shahaf Shuler]

Friday, May 11, 2018 7:09 PM, Andrew Rybchenko:
On 05/11/2018 05:22 PM, Ferruh Yigit wrote:

I think we have the following options:



A. Rollback corresponding changes which remove checks from PMDs

     (at least some PMDs will be not affected).



B. Fail configure if unsupported offload is requested (all PMDs must be

converted

     in the release, so reporting of supported offloads must be correct) AND

     add check that offloads requested on Tx queue level (derived from

txq_flags)

     are supported at least somewhere (i.e. tx_offload_capa)



        Issue is not PMDs, they should support new offload API. Concern is breaking

         application which is out of our control.



        With current approach some old application may request invalid offload and PMD

        won't return an error to app, agreed this is a concern.

        But adding error returns will break same applications, in a better more obvious

        way, and has possibility to break more applications, ones really not concerned

        about offload may be hit as well.

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.