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

[Stephen Hemminger <stephen@networkplumber.org>]

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.