Wednesday, May 2, 2018 6:18 PM, Ferruh Yigit: > Subject: Re: [dpdk-dev] ethdev new offloading API switch in PMDs > > On 5/2/2018 2:44 PM, Shahaf Shuler wrote: > > Wednesday, May 2, 2018 4:28 PM, Ferruh Yigit: > >> Subject: Re: [dpdk-dev] ethdev new offloading API switch in PMDs > >> > >> On 5/2/2018 1:52 PM, Shahaf Shuler wrote: > >>> Wednesday, May 2, 2018 11:47 AM, Ferruh Yigit: > >>>> Subject: Re: [dpdk-dev] ethdev new offloading API switch in PMDs > >>>> > >>>> On 5/2/2018 6:34 AM, Shahaf Shuler wrote: > >>>>> Tuesday, May 1, 2018 5:01 PM, Ferruh Yigit: > >>>>>> Subject: ethdev new offloading API switch in PMDs > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Following PMDs still has .txq_flags in use, after basic grep, no > >>>>>> in-dept investigation done. > >>>>>> > >>>>>> With PMDs switch to new API, that flag no longer should be needed. > >>>>>> > >>>>>> Old applications still use it but ethdev converts them to the > >>>>>> offloads, so that PMDs can only concern about offloads. > >>>>>> > >>>>> > >>>>> Full removal of txq_flags can be done only after we will mitigate > >>>>> the > >>>> "queue offloads must match port offload" constrain. > >>>> > >>>> Why? What is the relation of the flag and constrain? > >>> > >>> The PMD has to know if to verify port offloads and queue offload > >> correlation. > >>> It is done by looking on the ETH_TXQ_FLAGS_IGNORE flag. > >> > >> Perhaps I am missing something but why done looking > >> ETH_TXQ_FLAGS_IGNORE flag? > >> > >> ETH_TXQ_FLAGS_IGNORE flag means application is using new API and > >> "offloads" > >> variable is valid instead of "txq_flags" > >> > >> ethdev uses this information to convert "txq_flags" to "offloads", > >> for PMD "offloads" are always valid. > >> > >> PMD can check [rt]xmode->offloads (port offloads) and > >> [rt]xq->offloads (queue > >> offloads) to verify between port and queue offloads. What is missing > >> in this check? > > > > Old application will not set this flag. It will also not set any > > txmode.offload, > as this is a new API. > > Correct. > > > The Tx offload stage comes only after on the tx_queue_setup. > > Yes, rte_eth_tx_queue_setup() calls rte_eth_convert_txq_flags() which > converts "txq_flags" to txq->offloads > > > So for such old application we cannot compare the Tx Queue offload to the > Tx port offloads, as the later one are 0. > > I see now, issue is not txq->offloads, it is txmode.offload. > > For old applications txmode.offload is not correct, ethdev doesn't convert Tx > port level offloads to new API. > So it is not completely correct to say PMDs switched to new offloading API, in > Tx side there is still some part from old API needs to be supported for old > application support.
As I said, it is being used only for the check with the port offloads. Otherwise it is not needed. > > Is there a reason not to set txmode.offload in rte_eth_tx_queue_setup() ? > I think it is error prone. Changing of the txmode should be only as part of the port configuration. > > And can we say, in PMDs "txq_flags" is only allowed for > 1- "queue offloads must match port offload" constrain. > 2- As part of dev_info->default_txconf, for old applications. > > (1) can go away when constrain removed, target is this release. (2) can go > away when old API support deprecated from applications, target is next > release, is this correct? Seems correct. > > > > > >> > >>> > >>> When we mitigate the constraion/deprecate the old API we can remove > >> this. > >>> > >>>> Independent from constrain all PMDs switch to new API which doesn't > >>>> use txq_flags anymore, what blocks removing it from PMDs? > >>>> > >>>>> > >>>>>> Can maintainer of following PMDs please check their offloading > >>>>>> API > >>>>>> implementation: > >>>>>> > >>>>>> axgbe > >>>>>> bnxt > >>>>>> e1000 > >>>>>> ena > >>>>>> failsafe > >>>>>> fm10k > >>>>>> i40e > >>>>>> ixgbe > >>>>>> mlx4 > >>>>>> mlx5 > >>>>>> octeontx > >>>>>> qede > >>>>>> sfc > >>>>>> tap > >>>>>> thunderx > >>>>>> virtio > >>>>>> vmxnet3 > >>> > >
