Re: [dpdk-dev] ethdev new offloading API switch in PMDs

[Ferruh Yigit <ferruh.yigit@intel.com>]

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?

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