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 F1E1242DE6; Thu, 6 Jul 2023 11:37:29 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C3EFE410FA; Thu, 6 Jul 2023 11:37:29 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id C28CC40A79 for ; Thu, 6 Jul 2023 11:37:28 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 07B675C014D; Thu, 6 Jul 2023 05:37:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 06 Jul 2023 05:37:28 -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= 1688636248; x=1688722648; bh=cthNr0txQLhvShYmZMujeAM0MVQ2YRSEokx pG+FntTY=; b=lelPAHDQfKn0oZzeSA8dGGCkfqJYRmsaF6G18SBFYqqrKdoRWj/ eVasuAyS+uONh1RjzCnizVhe6PmTapHrbgZ9r6qj5Y7Iw50Z2inAb9UGjR6oxPnt a+a7ztHsf7ARfmDqvrwbXDN7ktIqZHCagt5TCsAixidks+cAtV5UmV3tuOasc508 Wi7Qmk/pOVZP8CQmRGV8XQ+HJ0AZpCYsaHg5am4djflhpugvEqD15EbHqnzK0RJj /0yi2AzLF0htHPagb2/VEZP672fUGhghG2i0WQEMmm7G3dJp/0/k1iBWDbWDrt6E RHLIzdfZrER6MDHqPSOsPsDns2OywB1T57g== 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= 1688636248; x=1688722648; bh=cthNr0txQLhvShYmZMujeAM0MVQ2YRSEokx pG+FntTY=; b=SUtpDUtUj3z7kAZQUfs956RuIwuCSXkqNQtaIw9MPUp4kBVa19U 66PZiu/+Mc7JqyDa1x8WvadUIBFY6lqoFaeAYwoROx7OmNiZs0KS/nNbH3CX6Xp2 /gO0/vpMaGg8z+TEiQSq32A4+ZjbYK1Zp1iWsqAeoBAIUWcGjIv3016FqeTyBkRJ NFQN4PkAKax6Thhh1IHAzOikAtmAD0CoabaBBKf23npLx7c/aMou4hGHIsX7Bhco NGPzV+1BfXyJlY4wQ3f3qQxK+jO74bv4QGrKuycahssLm+4PYUUXK1/bbPVhYclV neJE5cb9fgfPZzpr4ej0PbM1uFhcLFT7MRw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudelgddukecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddtieek gfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 6 Jul 2023 05:37:26 -0400 (EDT) From: Thomas Monjalon To: Stephen Hemminger , Bing Zhao Cc: dev@dpdk.org, Matan Azrad , Slava Ovsiienko , Ori Kam , Suanming Mou , Raslan Darawsheh , "dev@dpdk.org" , Michael Baum Subject: Re: [PATCH 1/7] net/mlx5: fix the modify field check of tag Date: Thu, 06 Jul 2023 11:37:24 +0200 Message-ID: <8931222.T7Z3S40VBb@thomas> In-Reply-To: References: <20230630054303.432238-1-bingz@nvidia.com> <20230629230831.10023261@hermes.local> 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 03/07/2023 15:31, Bing Zhao: > Hi Stephen, > If I understand correctly, do you mean that the internal value and rte_flow API value may have some conflict? > All the MLX5 internal enum values start from INT_MIN. When treating it as a int value, it would not have the same value with rte_flow enums, unless all the 2^^32 are defined. > But yes, this has some risk since there is no limitation of the values in the rte_flow API. We can assume it will never happen. This is good to go. > > -----Original Message----- > > From: Stephen Hemminger > > Sent: Friday, June 30, 2023 2:09 PM > > To: Bing Zhao > > Cc: Matan Azrad ; Slava Ovsiienko > > ; Ori Kam ; Suanming Mou > > ; Raslan Darawsheh ; > > dev@dpdk.org; Michael Baum > > Subject: Re: [PATCH 1/7] net/mlx5: fix the modify field check of tag > > > > External email: Use caution opening links or attachments > > > > > > On Fri, 30 Jun 2023 08:43:03 +0300 > > Bing Zhao wrote: > > > > > @@ -1117,9 +1117,10 @@ flow_dv_fetch_field(const uint8_t *data, > > > uint32_t size) static inline bool > > > flow_modify_field_support_tag_array(enum rte_flow_field_id field) { > > > - switch (field) { > > > + switch ((int)field) { > > > case RTE_FLOW_FIELD_TAG: > > > case RTE_FLOW_FIELD_MPLS: > > > + case MLX5_RTE_FLOW_FIELD_META_REG: > > > > Mixing internal and API fields seems like something that could get easily > > broken by changes to rte_flow. >