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

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

[Ferruh Yigit]

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.

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

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

[Shahaf Shuler]

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. 

> 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

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

[Ferruh Yigit]

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

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

[Shahaf Shuler]

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.

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

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

[Ferruh Yigit]

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
> 

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

[Shahaf Shuler]

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. The Tx offload stage comes only after on the tx_queue_setup.
So for such old application we cannot compare the Tx Queue offload to the Tx port offloads, as the later one are 0. 

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

Re: [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
>>>
> 

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

[Shahaf Shuler]

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