On Mon, 30 May 2022 18:45:26 +0530 <jer...@marvell.com> wrote: > From: Jerin Jacob <jer...@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 <jer...@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.
