From: Stephen Hemminger <stephen@networkplumber.org>
To: <jerinj@marvell.com>
Cc: <dev@dpdk.org>, Ferruh Yigit <ferruh.yigit@xilinx.com>,
Thomas Monjalon <thomas@monjalon.net>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
<ajit.khaparde@broadcom.com>, <aboyer@pensando.io>,
<beilei.xing@intel.com>, <bruce.richardson@intel.com>,
<chas3@att.com>, <chenbo.xia@intel.com>, <ciara.loftus@intel.com>,
<dsinghrawat@marvell.com>, <ed.czeck@atomicrules.com>,
<evgenys@amazon.com>, <grive@u256.net>, <g.singh@nxp.com>,
<zhouguoyang@huawei.com>, <haiyue.wang@intel.com>,
<hkalra@marvell.com>, <heinrich.kuhn@corigine.com>,
<hemant.agrawal@nxp.com>, <hyonkim@cisco.com>,
<igorch@amazon.com>, <irusskikh@marvell.com>,
<jgrajcia@cisco.com>, <jasvinder.singh@intel.com>,
<jianwang@trustnetic.com>, <jiawenwu@trustnetic.com>,
<jingjing.wu@intel.com>, <johndale@cisco.com>,
<john.miller@atomicrules.com>, <linville@tuxdriver.com>,
<keith.wiles@intel.com>, <kirankumark@marvell.com>,
<oulijun@huawei.com>, <lironh@marvell.com>,
<longli@microsoft.com>, <mw@semihalf.com>, <spinler@cesnet.cz>,
<matan@nvidia.com>, <matt.peters@windriver.com>,
<maxime.coquelin@redhat.com>, <mk@semihalf.com>,
<humin29@huawei.com>, <pnalla@marvell.com>,
<ndabilpuram@marvell.com>, <qiming.yang@intel.com>,
<qi.z.zhang@intel.com>, <radhac@marvell.com>,
<rahul.lakkireddy@chelsio.com>, <rmody@marvell.com>,
<rosen.xu@intel.com>, <sachin.saxena@oss.nxp.com>,
<skoteshwar@marvell.com>, <shshaikh@marvell.com>,
<shaibran@amazon.com>, <shepard.siegel@atomicrules.com>,
<asomalap@amd.com>, <somnath.kotur@broadcom.com>,
<sthemmin@microsoft.com>, <steven.webster@windriver.com>,
<skori@marvell.com>, <mtetsuyah@gmail.com>, <vburru@marvell.com>,
<viacheslavo@nvidia.com>, <xiao.w.wang@intel.com>,
<cloud.wangxiaoyun@huawei.com>, <yisen.zhuang@huawei.com>,
<yongwang@vmware.com>, <xuanziyang2@huawei.com>,
<cristian.dumitrescu@intel.com>
Subject: Re: [dpdk-dev] [RFC PATCH] ethdev: support congestion management
Date: Tue, 31 May 2022 09:09:08 -0700 [thread overview]
Message-ID: <20220531090908.73db7d77@hermes.local> (raw)
In-Reply-To: <20220530131526.3598658-1-jerinj@marvell.com>
On Mon, 30 May 2022 18:45:26 +0530
<jerinj@marvell.com> wrote:
> From: Jerin Jacob <jerinj@marvell.com>
>
> NIC HW controllers often come with congestion management support on
> various HW objects such as Rx queue depth or mempool queue depth.
>
> Also, it can support various modes of operation such as RED
> (Random early discard), WRED etc on those HW objects.
>
> This patch adds a framework to express such modes(enum rte_cman_mode)
> and introduce (enum rte_eth_cman_obj) to enumerate the different
> objects where the modes can operate on.
>
> This patch adds RTE_CMAN_RED mode of operation and
> RTE_ETH_CMAN_OBJ_RX_QUEUE, RTE_ETH_CMAN_OBJ_RX_QUEUE_MEMPOOL object.
>
> Introduced reserved fields in configuration structure
> backed by rte_eth_cman_config_init() to add new configuration
> parameters without ABI breakage.
>
> Added rte_eth_cman_info_get() API to get the information such as
> supported modes and objects.
>
> Added rte_eth_cman_config_init(), rte_eth_cman_config_set() APIs
> to configure congestion management on those object with associated mode.
>
> Finally, Added rte_eth_cman_config_get() API to retrieve the
> applied configuration.
>
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
The concept of supporting hardware queue management is good, but would like
to make some suggestions:
The hardware support of QOS should ideally be part of the existing DPDK
traffic management. For example, in Linux there are devices that can offload
traffic control (TC) to hardware and this is done via flags to existing
software infrastructure.
Your implementation makes HW and SW QoS diverge. This will require each application
to get even more dependent on a particular hardware device.
Which brings up the bigger picture problem. Don't want to repeat the problems
with rte_flow here. Any hardware support needs to have a matching set of software
implementation, and test cases. The problem with rte_flow is the semantics are
poorly defined and each vendor does it differently; and the SW flow classifier
is incomplete and does not match what the HW does.
In an ideal world, there would be:
- an abstract API for defining ingress and egress queue management
- a software implementation of that API
- multiple hardware implementations
- ability to transparently use both SW and HW queue management from application
- complete test suite for that API.
Yes, that is asking a lot. But as trailblazer in this area, you have to do the
hard work.
next prev parent reply other threads:[~2022-05-31 16:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-30 13:15 jerinj
2022-05-30 19:43 ` Ajit Khaparde
2022-07-13 12:11 ` Jerin Jacob
2022-05-31 1:09 ` Min Hu (Connor)
2022-07-13 12:16 ` Jerin Jacob
2022-05-31 16:09 ` Stephen Hemminger [this message]
2022-07-13 12:25 ` Jerin Jacob
2022-07-13 13:03 ` [dpdk-dev] [PATCH v1] " jerinj
2022-09-19 12:15 ` [PATCH v2 1/1] " skori
2022-09-27 14:36 ` Thomas Monjalon
2022-09-27 15:09 ` Bruce Richardson
2022-09-28 11:14 ` Jerin Jacob
2022-09-28 12:08 ` Thomas Monjalon
2022-09-28 12:23 ` Jerin Jacob
2022-09-28 13:07 ` Olivier Matz
2022-09-28 8:19 ` Andrew Rybchenko
2022-09-28 12:20 ` Jerin Jacob
2022-09-29 9:35 ` [PATCH v3 " skori
2022-10-04 9:02 ` Andrew Rybchenko
2022-10-04 9:04 ` Andrew Rybchenko
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=20220531090908.73db7d77@hermes.local \
--to=stephen@networkplumber.org \
--cc=aboyer@pensando.io \
--cc=ajit.khaparde@broadcom.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=asomalap@amd.com \
--cc=beilei.xing@intel.com \
--cc=bruce.richardson@intel.com \
--cc=chas3@att.com \
--cc=chenbo.xia@intel.com \
--cc=ciara.loftus@intel.com \
--cc=cloud.wangxiaoyun@huawei.com \
--cc=cristian.dumitrescu@intel.com \
--cc=dev@dpdk.org \
--cc=dsinghrawat@marvell.com \
--cc=ed.czeck@atomicrules.com \
--cc=evgenys@amazon.com \
--cc=ferruh.yigit@xilinx.com \
--cc=g.singh@nxp.com \
--cc=grive@u256.net \
--cc=haiyue.wang@intel.com \
--cc=heinrich.kuhn@corigine.com \
--cc=hemant.agrawal@nxp.com \
--cc=hkalra@marvell.com \
--cc=humin29@huawei.com \
--cc=hyonkim@cisco.com \
--cc=igorch@amazon.com \
--cc=irusskikh@marvell.com \
--cc=jasvinder.singh@intel.com \
--cc=jerinj@marvell.com \
--cc=jgrajcia@cisco.com \
--cc=jianwang@trustnetic.com \
--cc=jiawenwu@trustnetic.com \
--cc=jingjing.wu@intel.com \
--cc=john.miller@atomicrules.com \
--cc=johndale@cisco.com \
--cc=keith.wiles@intel.com \
--cc=kirankumark@marvell.com \
--cc=linville@tuxdriver.com \
--cc=lironh@marvell.com \
--cc=longli@microsoft.com \
--cc=matan@nvidia.com \
--cc=matt.peters@windriver.com \
--cc=maxime.coquelin@redhat.com \
--cc=mk@semihalf.com \
--cc=mtetsuyah@gmail.com \
--cc=mw@semihalf.com \
--cc=ndabilpuram@marvell.com \
--cc=oulijun@huawei.com \
--cc=pnalla@marvell.com \
--cc=qi.z.zhang@intel.com \
--cc=qiming.yang@intel.com \
--cc=radhac@marvell.com \
--cc=rahul.lakkireddy@chelsio.com \
--cc=rmody@marvell.com \
--cc=rosen.xu@intel.com \
--cc=sachin.saxena@oss.nxp.com \
--cc=shaibran@amazon.com \
--cc=shepard.siegel@atomicrules.com \
--cc=shshaikh@marvell.com \
--cc=skori@marvell.com \
--cc=skoteshwar@marvell.com \
--cc=somnath.kotur@broadcom.com \
--cc=spinler@cesnet.cz \
--cc=steven.webster@windriver.com \
--cc=sthemmin@microsoft.com \
--cc=thomas@monjalon.net \
--cc=vburru@marvell.com \
--cc=viacheslavo@nvidia.com \
--cc=xiao.w.wang@intel.com \
--cc=xuanziyang2@huawei.com \
--cc=yisen.zhuang@huawei.com \
--cc=yongwang@vmware.com \
--cc=zhouguoyang@huawei.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).