On 5/13/2018 6:30 AM, Shahaf Shuler wrote: > 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.
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?
