From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F030EA0032; Wed, 13 Jul 2022 14:26:08 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CC3434282D; Wed, 13 Jul 2022 14:26:08 +0200 (CEST) Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) by mails.dpdk.org (Postfix) with ESMTP id 7DD904280D for ; Wed, 13 Jul 2022 14:26:07 +0200 (CEST) Received: by mail-qk1-f180.google.com with SMTP id o21so355635qkm.10 for ; Wed, 13 Jul 2022 05:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bpnIYQjt7HMMr3VyzKU2iO9XslO/b7C1zKXflC+DRyk=; b=eKJjJGxVmApjNKkFElPtTVFqetcJNFbcWt2K7DWwqi/S6AmLU6cv90/kTsFie0CG7z LAeRW+7txm3BkKdK4FaBXHdO4WAT+8ng9TNelHkLSlGQ6EEmWNx/J8YB9RPZ3WvQNtns lhjJXwwjdF8k1dkcDYvieQG/l/T6C/x2/O5jIgln9vcRBH3vPZa/fe8cRq6e4pHjGWOS ymDBF8feWQN/GYspi+NoOlGlhqeFjaeRGUSgO40O5aa32U7DV0NiqjzO3H3Pp27aAQmx 3lwA75xdRR1hZwMepWsIkMAqxv7LSH4opalYWj9fc6L+92hvt+w1+Hm/luNHHBvZk/fo aPzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bpnIYQjt7HMMr3VyzKU2iO9XslO/b7C1zKXflC+DRyk=; b=DDO1jN5HiW7wyfFA9r7h/Xcuwe+XhswZMaiWWE+NVhh6sUgvCSCEXizitvIWnJbIcx gvAbh5b5EEdZD0LAkRqcSPToidBEJhVLWe1B85d27ekOMtpiJyN/osTflW6o8UKD/jxn hgI5jXSQmD7CAUxiNBVqN7hMy+S3xn6mVoQLOZmGxygGK6uA1iyZ5f6lJbibtF727MGt dcyYIoR6Y2MV8uSYPnuk+fHyn0BPhRxPX/gc+B1dLfbpkeTz5n55eGPvfxzq0/RmKIGV M5MQABNijbG8NKUZgG4WdsUybzLnba3vJN4t4TeGvLIqMl6FTDmbXA8I4L0vs+AFIIn4 oLSQ== X-Gm-Message-State: AJIora87/hSQmLK1DcgTo2b+tsv2OPzDWkS2hiI4Pdv3alMLccbt4xuB T0M0Br72n6FLan6LciREA61P4/jn8aUyVAh/xPQ= X-Google-Smtp-Source: AGRyM1v1ifqdyft8VR6kYTLL1EeSwvsqRsMANgBpbRCs6GJw9rhqtibIYqIBcigfaoSacIgfeFYZOF5Tg5qM4eRA1o4= X-Received: by 2002:a05:620a:22d5:b0:6b5:ba96:cc75 with SMTP id o21-20020a05620a22d500b006b5ba96cc75mr1152646qki.316.1657715166855; Wed, 13 Jul 2022 05:26:06 -0700 (PDT) MIME-Version: 1.0 References: <20220530131526.3598658-1-jerinj@marvell.com> <20220531090908.73db7d77@hermes.local> In-Reply-To: <20220531090908.73db7d77@hermes.local> From: Jerin Jacob Date: Wed, 13 Jul 2022 17:55:40 +0530 Message-ID: Subject: Re: [dpdk-dev] [RFC PATCH] ethdev: support congestion management To: Stephen Hemminger Cc: Jerin Jacob , dpdk-dev , Ferruh Yigit , Thomas Monjalon , Andrew Rybchenko , Ajit Khaparde , Andrew Boyer , Beilei Xing , "Richardson, Bruce" , Chas Williams , "Xia, Chenbo" , Ciara Loftus , Devendra Singh Rawat , Ed Czeck , Evgeny Schemeilin , Gaetan Rivet , Gagandeep Singh , Guoyang Zhou , Haiyue Wang , Harman Kalra , Heinrich Kuhn , Hemant Agrawal , Hyong Youb Kim , Igor Chauskin , Igor Russkikh , Jakub Grajciar , Jasvinder Singh , Jian Wang , Jiawen Wu , Jingjing Wu , John Daley , John Miller , "John W. Linville" , "Wiles, Keith" , Kiran Kumar K , Lijun Ou , Liron Himi , Long Li , Marcin Wojtas , Martin Spinler , Matan Azrad , Matt Peters , Maxime Coquelin , Michal Krawczyk , "Min Hu (Connor" , Pradeep Kumar Nalla , Nithin Dabilpuram , Qiming Yang , Qi Zhang , Radha Mohan Chintakuntla , Rahul Lakkireddy , Rasesh Mody , Rosen Xu , Sachin Saxena , Satha Koteswara Rao Kottidi , Shahed Shaikh , Shai Brandes , Shepard Siegel , Somalapuram Amaranath , Somnath Kotur , Stephen Hemminger , Steven Webster , Sunil Kumar Kori , Tetsuya Mukawa , Veerasenareddy Burru , Viacheslav Ovsiienko , Xiao Wang , Xiaoyun Wang , Yisen Zhuang , Yong Wang , Ziyang Xuan , Cristian Dumitrescu Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, May 31, 2022 at 9:39 PM Stephen Hemminger wrote: > > On Mon, 30 May 2022 18:45:26 +0530 > wrote: > > > From: Jerin Jacob > > > > 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 > > 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. >