Re: [dpdk-dev] [RFC PATCH] ethdev: support congestion management

[Jerin Jacob <jerinjacobk@gmail.com>]

On Tue, May 31, 2022 at 9:39 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> 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

It is already available as rte_tm and rte_mtr API. Only congestion
management is missing. That is added in the patch.


> - a software implementation of that API

It is already available. See lib/sched/rte_red.h

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

None of the new features in rte_flow, rte_ethdev or rte_tm etc NOT
going in this path.
If we think, we need to enforce this path(SW driver is a must) for any
feature. Let's discuss here and TB meeting and decide and
we need to make that policy for any new contribution.



>