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

[Shahaf Shuler <shahafs@mellanox.com>]

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