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