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

[Ferruh Yigit]

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.

Is there a reason not to set txmode.offload in rte_eth_tx_queue_setup() ?


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?


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