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 18ED4A00C2; Tue, 27 Sep 2022 16:36:24 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BA12B41133; Tue, 27 Sep 2022 16:36:23 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 5574240694 for ; Tue, 27 Sep 2022 16:36:22 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id C2D145C010E; Tue, 27 Sep 2022 10:36:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 27 Sep 2022 10:36:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1664289381; x= 1664375781; bh=zDxr3r7+pIUaYWK95D7o20zLm2m7EGkyoEjBXXULTm0=; b=Z Mw279oGUO9ZsfGc3sY3VjqtbutuC9k0LjMNeTt1e3yNo+iw6Wnsc8QcPsrDuRJlc t2enWgaPj+HFUKaNRLnYMjerWc2/D54p957OvDE+0ncWLIJE8QSKommb+pdzG5J+ ZU2eyTuEUUXMUdRMOCj0Y2jv/yxDj/qkBXEBnxv62KQAYqVwgEVOjneIIiGPe6MM lGIMaqxataQOR4QJJmjUDv5gejs81E4zIQPNcmRxWK+8NRoLJPyrozreD8YGRGPo cPqMQ0gizqRWoSTYj1yV5nMnrGh30Mv9bSnUBCa0Reo+w+shYEK/dIexn2OlzgXv lqXtKMEle3Wy/GNwbRf/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1664289381; x= 1664375781; bh=zDxr3r7+pIUaYWK95D7o20zLm2m7EGkyoEjBXXULTm0=; b=R fANbQYLXQMo5/wIhqRET3HPnNDvY+b+f277ld2M42MdiwwEonytFrKla4E9a503l n5q5X+RcQk8HEjMKKuHlQEOYT3CpSDcYdBWpTeU+o8CZ09tSTXIsh/NmljhmyOIV Zb8qbT6lGmC/JWf53lFZMkvh/xlfAz9b0cBTVa46auRhhzFqShfou2tyIDbAJB6T HKOYe5nojLCmQChuvlunUoy/YdwVy8OG2VjeNNvv8csvZJp019LlHXpF6WhpAOPn OLAEXlrQflPnUu/LQoLWl6y91Iq1bHTdA+EWYwjXgEDz0UXQTLxbvdjxxtWYCwX3 w9SAs0YOpStUAzDZiv2/A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeegiedgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtvdefgfdtleeiuddvvdelkefgfeelkeetvedthffhjeevteeg tdfhudfgueejieenucffohhmrghinhepvghthhguvghvrdguvggrlhenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhj rghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 27 Sep 2022 10:36:20 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob , skori@marvell.com Cc: Ferruh Yigit , Andrew Rybchenko , dev@dpdk.org, david.marchand@redhat.com, orika@nvidia.com Subject: Re: [PATCH v2 1/1] ethdev: support congestion management Date: Tue, 27 Sep 2022 16:36:18 +0200 Message-ID: <2199859.3ZeAukHxDK@thomas> In-Reply-To: <20220919121534.1058884-1-skori@marvell.com> References: <20220713130340.2886839-1-jerinj@marvell.com> <20220919121534.1058884-1-skori@marvell.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 19/09/2022 14:15, skori@marvell.com: > 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. [...] > doc/guides/nics/features.rst | 12 +++ > doc/guides/nics/features/default.ini | 1 + > lib/eal/include/meson.build | 1 + > lib/eal/include/rte_cman.h | 55 ++++++++++ > lib/ethdev/ethdev_driver.h | 25 +++++ > lib/ethdev/meson.build | 1 + > lib/ethdev/rte_cman.c | 101 ++++++++++++++++++ > lib/ethdev/rte_ethdev.h | 151 +++++++++++++++++++++++++++ > lib/ethdev/version.map | 6 ++ I feel EAL is not the right place for CMAN definitions. After a discussion with Jerin, I understand we could use the same definitions in other API classes, not only ethdev. However I think this .h file should be better hosted in lib/ethdev/ with its own namespace rte_cman. Then other libs could include this rte_cman.h without having a strong dependency on ethdev. Deal?