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 3E6BB42D8D; Thu, 29 Jun 2023 17:33:48 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 23738410F1; Thu, 29 Jun 2023 17:33:48 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id D7D0140EDB for ; Thu, 29 Jun 2023 17:33:46 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5569C5C006F; Thu, 29 Jun 2023 11:33:46 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 29 Jun 2023 11:33:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type: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= 1688052826; x=1688139226; bh=s9wwzrm/MEKBEJCBi4KwYodQsxLKCY/18nr 6gJGxGQE=; b=MlMpP0h9/DnY1J7ivt3/8jHZJmzYNyhWYvjnzRHMMnlxUg+Ra3O naBFpSWfitiGN3QSGkTwAl8dFuucbDjI38hLLEvsZHtL4wPGOTclfFVb14slnqgw 2cUo1V/chPaoNfspQxAz/rPwachS/aPQI2xkRrtbQSkIyW9YO/lGGXzyJJrH2LB2 gxBf3CCZTFStiM9UBp+Q9809juWkwjQGtuF/p+/LbGklB2BNy6W4dvgyA4vvHsgf QoMiVahTv1vluQtTCTSPjCHV1Ndri8vxZ6EyYlWcKrbLrl5mBlHo56rm2ZGj+t+D CongrHbO3gEwCq0ih+fPzjjI6TakqkxeIsA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type: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= 1688052826; x=1688139226; bh=s9wwzrm/MEKBEJCBi4KwYodQsxLKCY/18nr 6gJGxGQE=; b=LHd65RwgACsa8YMeSS3FuRoOF8YRl6o1Z/Ho/Ie1/umfufPiMPr ZJoJatwaWNTTEEV4HV/3ra3Cq1oOZ+yqU/hQwV50CNexYzrJwYI06cI4ZxWN9T7p ZI+mGqTc0yTvVzgL0texvJQ7mJKL4pTz/5dwUtBxjvuRirsCeWs6u3yF3qVGt1xC CBG3GekzkpYJEfA0gaDyAEQzzpPrDBxgZ5IAkFlwHVp+37HV8FrUOAdSynt59lT3 60AOfhIz55jkJXANY/XVoLMIA/KKNMy9oNHyi05yQ2Dd0CHdf9aXR2cr+YMy5oxz SFjHoXPRS367aW2zqnFtz3voE0mpQ50N7pg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrtdeggdeltdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepjeejffffgfffkeefffelgfekleetjeffleeludeghfehleffteeh veduffdugfdvnecuffhomhgrihhnpeguphgukhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhn rdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 29 Jun 2023 11:33:44 -0400 (EDT) From: Thomas Monjalon To: Ori Kam , Ferruh Yigit , Kiran Kumar K Cc: dev@dpdk.org, Aman Singh , Yuying Zhang , Andrew Rybchenko , dev@dpdk.org Subject: Re: [PATCH v2] ethdev: add Tx queue flow matching item Date: Thu, 29 Jun 2023 17:33:43 +0200 Message-ID: <6009006.NeCsiYhmir@thomas> In-Reply-To: <3422979.uBEoKPz9u1@thomas> References: <20230508134935.971197-1-kirankumark@marvell.com> <3422979.uBEoKPz9u1@thomas> 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 08/06/2023 21:59, Thomas Monjalon: > 08/05/2023 15:49, kirankumark@marvell.com: > > From: Kiran Kumar K > > > > Adding support for Tx queue flow matching item. > > This item is valid only for egress rules. > > An example use case would be that application can > > set different vlan insert rules with different PCP values > > based on Tx queue number. > > > > Signed-off-by: Kiran Kumar K > > --- > > app/test-pmd/cmdline_flow.c | 28 +++++++++++++++++++++ > > doc/guides/prog_guide/rte_flow.rst | 7 ++++++ > > doc/guides/rel_notes/release_23_07.rst | 5 ++++ > > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 4 +++ > > lib/ethdev/rte_flow.c | 1 + > > lib/ethdev/rte_flow.h | 26 +++++++++++++++++++ > > 6 files changed, 71 insertions(+) > > That's only 71 lines but I could make 10 comments. > I'm fixing spacing, alignment, sorting, etc while pulling next-net, > but it would have been more confortable if more attention was paid > by the author and the reviewers. > > > I have a question though (it could be fixed in a later patch): > > > +struct rte_flow_item_tx_queue { > > + /** Tx queue number that packet is being transmitted */ > > + uint16_t tx_queue; > > +}; > > This field is used with host endianness, right? > > > +static const struct rte_flow_item_tx_queue rte_flow_item_tx_queue_mask = { > > + .tx_queue = RTE_BE16(0xffff), > > +}; > > So why using RTE_BE16 to set a field which is not specifically big endian? > (not talking about the fact that 0xffff is the same no matter the endianness, > and not talking about the fact that it is better to use UINT16_MAX). Repeating again: This patch has bad quality, bad review, I've noticed something wrong, and there are 0 comments or reply! Now David has sent a fix for this: https://patches.dpdk.org/project/dpdk/patch/20230629135839.974700-1-david.marchand@redhat.com/ Don't expect next patches to be merged quickly.