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 DD6DBA0548; Tue, 31 May 2022 18:09:15 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8DAE54067B; Tue, 31 May 2022 18:09:15 +0200 (CEST) Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) by mails.dpdk.org (Postfix) with ESMTP id 2F80E40143 for ; Tue, 31 May 2022 18:09:14 +0200 (CEST) Received: by mail-pf1-f174.google.com with SMTP id w21so2439372pfc.0 for ; Tue, 31 May 2022 09:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=FyDYbRv53ue7TlUyfUY+vR/lOGysOw8exA/Npczhjdc=; b=1bRCx6XBtoQhZX+HPRBbUyv7pPvEYOa+c5aH2sWmWftzij1izHR1gtEHde5khEXIsZ mMlOefoCJkJlL+xRbIKKVIQMEqY8bQ8IzRY3cKRkrnz/Nq9fKe3m5AtNh/fQk2vUOUEi FxIgV5lvy/GtobcPFA8XEQoih5nkMYgxkDuZG7a4Dg5+TolP0fKNKBzA16g2tRXI3NZY ljYGiNPmoETHr5Nqvasy+NpmhH53HZFfSWaTTlgj0vRWNclGhYYL/MiaIy1JEPHn0vRG HOhX/Jntbg07hsmnOyLL6KBw4z28NkUUX/+dIVeOZFawfM8Ciw6sm+Daizayo4kOL+Uy jt5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=FyDYbRv53ue7TlUyfUY+vR/lOGysOw8exA/Npczhjdc=; b=UBqkDe5F+4YXYV+OY7AJXaHvyMp+OitS2JLI4jdrPxBwIK5iew5OaS94588DkXWVYT WufVuKtAIZmngwWIN6fpGcD2PXOnt4XhfqlMD94GpiHZkwjjaj0g3UAC+o10V5kdbhZY i3zlV5UH/Oud68Wz4wDSXPrNwlt+nT1XrBRCWGTbHPqB5B1qDE8X5f/pdQcsuCa+BqcF +tBAAE/XeDRshmiq68GaV7raW+HQmwzWomKbhW7ksHvPOjaHz5haEOIiNF3BhAaj58HU 62p2WseNpHHUcOryu6PJMNvuseJqN3FhQtRswNhKeDtESaVva4P1bGPfuCJZROX16ecS yGuw== X-Gm-Message-State: AOAM531GzxR5QcYRcrmNGYac2aPyLd/DkN2rpHExSlFG8Oc/hyNUxNRe B18DcN4AbZNesdsMphCBUC7v7A== X-Google-Smtp-Source: ABdhPJxMo0NfyR+ORTEo0lbP8ryMdRLXnECWo9DQKwH9o+Xs4vrqC/H76jOosJnzs6SdLIX9GOn1Ow== X-Received: by 2002:a62:cd42:0:b0:519:3e17:bc80 with SMTP id o63-20020a62cd42000000b005193e17bc80mr20178636pfg.71.1654013353228; Tue, 31 May 2022 09:09:13 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id g20-20020aa78754000000b00517c84fd24asm11240469pfo.172.2022.05.31.09.09.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 May 2022 09:09:12 -0700 (PDT) Date: Tue, 31 May 2022 09:09:08 -0700 From: Stephen Hemminger To: Cc: , Ferruh Yigit , Thomas Monjalon , Andrew Rybchenko , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [dpdk-dev] [RFC PATCH] ethdev: support congestion management Message-ID: <20220531090908.73db7d77@hermes.local> In-Reply-To: <20220530131526.3598658-1-jerinj@marvell.com> References: <20220530131526.3598658-1-jerinj@marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 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 - 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.