From: Ferruh Yigit <ferruh.yigit@intel.com>
To: "Shahaf Shuler" <shahafs@mellanox.com>,
"Gaetan Rivet" <gaetan.rivet@6wind.com>,
"Qi Zhang" <qi.z.zhang@intel.com>,
"Xiao Wang" <xiao.w.wang@intel.com>,
"Beilei Xing" <beilei.xing@intel.com>,
"Wenzhuo Lu" <wenzhuo.lu@intel.com>,
"Konstantin Ananyev" <konstantin.ananyev@intel.com>,
"Adrien Mazarguil" <adrien.mazarguil@6wind.com>,
"Nélio Laranjeiro" <nelio.laranjeiro@6wind.com>,
"Yongseok Koh" <yskoh@mellanox.com>,
"Santosh Shukla" <santosh.shukla@caviumnetworks.com>,
"Jerin Jacob" <jerin.jacob@caviumnetworks.com>,
"Rasesh Mody" <rasesh.mody@cavium.com>,
"Harish Patil" <harish.patil@cavium.com>,
"Shahed Shaikh" <shahed.shaikh@cavium.com>,
"Andrew Rybchenko" <arybchenko@solarflare.com>,
"Pascal Mazon" <pascal.mazon@6wind.com>,
"Maciej Czekaj" <maciej.czekaj@caviumnetworks.com>,
"Maxime Coquelin" <maxime.coquelin@redhat.com>,
"Tiwei Bie" <tiwei.bie@intel.com>,
"Yong Wang" <yongwang@vmware.com>
Cc: Thomas Monjalon <thomas@monjalon.net>, dpdk-dev <dev@dpdk.org>,
Ravi Kumar <ravi1.kumar@amd.com>,
Ajit Khaparde <ajit.khaparde@broadcom.com>,
Somnath Kotur <somnath.kotur@broadcom.com>,
Marcin Wojtas <mw@semihalf.com>,
Michal Krawczyk <mk@semihalf.com>,
Guy Tzalik <gtzalik@amazon.com>,
Evgeny Schemeilin <evgenys@amazon.com>,
Bruce Richardson <bruce.richardson@intel.com>
Subject: Re: [dpdk-dev] ethdev new offloading API switch in PMDs
Date: Wed, 2 May 2018 16:18:24 +0100 [thread overview]
Message-ID: <8e92448e-f9b0-e8bf-91db-005259412eb0@intel.com> (raw)
In-Reply-To: <DB7PR05MB44262D90F856DD4F10EB698DC3800@DB7PR05MB4426.eurprd05.prod.outlook.com>
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
>>>
>
next prev parent reply other threads:[~2018-05-02 15:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-01 14:01 Ferruh Yigit
2018-05-02 5:34 ` Shahaf Shuler
2018-05-02 8:46 ` Ferruh Yigit
2018-05-02 12:52 ` Shahaf Shuler
2018-05-02 13:27 ` Ferruh Yigit
2018-05-02 13:44 ` Shahaf Shuler
2018-05-02 15:18 ` Ferruh Yigit [this message]
2018-05-02 17:42 ` Shahaf Shuler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8e92448e-f9b0-e8bf-91db-005259412eb0@intel.com \
--to=ferruh.yigit@intel.com \
--cc=adrien.mazarguil@6wind.com \
--cc=ajit.khaparde@broadcom.com \
--cc=arybchenko@solarflare.com \
--cc=beilei.xing@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=evgenys@amazon.com \
--cc=gaetan.rivet@6wind.com \
--cc=gtzalik@amazon.com \
--cc=harish.patil@cavium.com \
--cc=jerin.jacob@caviumnetworks.com \
--cc=konstantin.ananyev@intel.com \
--cc=maciej.czekaj@caviumnetworks.com \
--cc=maxime.coquelin@redhat.com \
--cc=mk@semihalf.com \
--cc=mw@semihalf.com \
--cc=nelio.laranjeiro@6wind.com \
--cc=pascal.mazon@6wind.com \
--cc=qi.z.zhang@intel.com \
--cc=rasesh.mody@cavium.com \
--cc=ravi1.kumar@amd.com \
--cc=santosh.shukla@caviumnetworks.com \
--cc=shahafs@mellanox.com \
--cc=shahed.shaikh@cavium.com \
--cc=somnath.kotur@broadcom.com \
--cc=thomas@monjalon.net \
--cc=tiwei.bie@intel.com \
--cc=wenzhuo.lu@intel.com \
--cc=xiao.w.wang@intel.com \
--cc=yongwang@vmware.com \
--cc=yskoh@mellanox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).