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 B03BE42C63; Thu, 8 Jun 2023 21:59:37 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 75377410D3; Thu, 8 Jun 2023 21:59:37 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id B0D6E410D3 for ; Thu, 8 Jun 2023 21:59:36 +0200 (CEST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3233F5C0246; Thu, 8 Jun 2023 15:59:34 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Thu, 08 Jun 2023 15:59:34 -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=fm1; t= 1686254374; x=1686340774; bh=YH/B21j/OWIoRt5kjn6ePxPoeMtXZoCZFDc AAaHb6lU=; b=w157k688Godoflos1AA3Fo6hvZ0Ysf7wOQajALuRgmPcPz/NwXO EyXSUHdmI2Ir6W+t9/TydtwE8B4xKgc6A1p8vo4Bm6GZ7edpDXonM6K+mkCwtpSP 07BWNnr5N2ONzryN/LsfUoLuQf658mUT2YtcfMNdFCs5DWO/JliSDHFJGFq62vgR Eo2x8OQUqIjs3GAb3G9RsvSjEUSHP+ks/OkZVFo+kuTHAliwqQHQKaRkP+C2xHL2 88W7uZyeftQ18woLEix4KNCtBYhgRulqE4BSjTUETJ8LD9Gqv0OYwDZzPTMvT+Qt gKguRL5KMRpRzsIfYTxfsbtmLLYdD5GcbaQ== 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=fm1; t= 1686254374; x=1686340774; bh=YH/B21j/OWIoRt5kjn6ePxPoeMtXZoCZFDc AAaHb6lU=; b=PKkXIac/VkVFShiz79v1q4IHT0ZskD1TrO76rpfNjUYS9IvKqfP aWVzteE/o3gb56AlQiVDduCTteUU8ByKn9JXUHfQwSCuSTp97LfJG0+qUsmGlMZP jqyHXmIGWOFkhnnYmNCmuPPMCC4u1quxw1rzpQz5OPdgPVkOF3RaasNZeOxj8xFt xaXVFO7LRcOLn+EDrDHqCtUuJgkeB1xtwaa1RuUy0/8en7j/h0kV+UYjXA/AQ82Q ti8Ubhw1fGSBHWhTz1/jRO+78bYKxb/OUQPrVTxi+C6ADR5Rpx77h9Iiox+dqDcc MLKQpgd3OjAI3nvcZFmjJcU0wA7/AUUzUzA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgedtiedgudeggecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhho mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne cuggftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddt ieekgfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 8 Jun 2023 15:59:32 -0400 (EDT) From: Thomas Monjalon To: Ori Kam , Ferruh Yigit , Kiran Kumar K Cc: Aman Singh , Yuying Zhang , Andrew Rybchenko , dev@dpdk.org Subject: Re: [PATCH v2] ethdev: add Tx queue flow matching item Date: Thu, 08 Jun 2023 21:59:30 +0200 Message-ID: <3422979.uBEoKPz9u1@thomas> In-Reply-To: <20230508134935.971197-1-kirankumark@marvell.com> References: <20230508134935.971197-1-kirankumark@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 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).