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 AB05B4415C; Wed, 5 Jun 2024 11:35:38 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 96619402DC; Wed, 5 Jun 2024 11:35:38 +0200 (CEST) Received: from fhigh4-smtp.messagingengine.com (fhigh4-smtp.messagingengine.com [103.168.172.155]) by mails.dpdk.org (Postfix) with ESMTP id 5D73E40289 for ; Wed, 5 Jun 2024 11:35:37 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailfhigh.nyi.internal (Postfix) with ESMTP id D745611401F8; Wed, 5 Jun 2024 05:35:36 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 05 Jun 2024 05:35:36 -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:subject:subject:to:to; s=fm1; t=1717580136; x=1717666536; bh=4EPB2TlwRa5p1NipRAClj0rLIb2Uz6xOfzb4hEmRpbM=; b= Tnt2pwBw28QtEuprL4tvQVi/rMKp6UcVS2bF0g0uo16eT3+F2vAsJbIqu8EMJ9Sq pwDbPYvg+/nEq2hNT7CYiPKScMe681voDgfHVcKiMBTg2fuQSJYg6SL2EPqve1Es uq5J1nKvZoprMmHS11yfStDh85eXZcZTrFZkr+HbsNLvcUIqVSWR49SDH3UCkVON o5ekxzcOrzVb2s9H/R4xljn+Az5wOtRFD/K+a/jZaJAu9uBCZ3HK8rJ5UXZB3MYW 4+aoOwp5+M/wrBLWFUWqVWQ3lgDUVZaKaGGlgg4ixRm6Tyf4X9VGxbkuquwNH00f aMQaVgohj9OHkmensuRr2Q== 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:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1717580136; x= 1717666536; bh=4EPB2TlwRa5p1NipRAClj0rLIb2Uz6xOfzb4hEmRpbM=; b=B qhQ/2BAytskKz3MHOeSyuobuMMBup8wm5yXh9qJw2AbJ/n9ExX6z6dMC6RsbCF9n V/kEZZcnOrdPVAQPrcNdkoiBjk9wCIFt7fKxKCfUgQIoB61bv81tTa6NayrIYxhK 1vFz6zfTMXPwTF6PJEr0Rca0L9aWO9/ZS9fbymIseZbbJ5DHYL+qORlgXIzjEhKT uQDrZk6yPraJ+6iN8Owd2OJmvAysxOPXPM9y3qrQZ6mvzj2BnAgV1bh4bi8pM4B/ VousyGD7+J1f5rtynKwlqXxNYTdL0jhMWM29NXocE7Y+tawC/r2X1QKMQfbdoS/x 80idnSIMWAm8HnVW6hjZA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvdeliedgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeejudevheeiveduuddtveffgfdtgeekueevjeffjeegtdeggeek gfdvuefgfeekjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 5 Jun 2024 05:35:34 -0400 (EDT) From: Thomas Monjalon To: rongwei liu Cc: Dariusz Sosnowski , dev@dpdk.org, Matan Azrad , Slava Ovsiienko , Ori Kam , Suanming Mou , Aman Singh , Yuying Zhang , Ferruh Yigit , Andrew Rybchenko Subject: Re: [PATCH v4 2/3] ethdev: add VXLAN last reserved field Date: Wed, 05 Jun 2024 11:35:32 +0200 Message-ID: <2286527.o7ts2hSHzF@thomas> In-Reply-To: References: <14937324.O6BkTfRZtg@thomas> <6114865.NeCsiYhmir@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" 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 05/06/2024 10:14, rongwei liu: > > > > > In this patch, "vxlan_last_rsvd" is used in testpmd, so it matches > > > > > existing "last_rsvd" field in VXLAN item. If we choose to use > > > > > "rsvd1", > > > > > we should probably rename all other instances of "last_rsvd" to > > > > > match.> > > > > > > > > > I prefer "vxlan_last_rsvd" for 2 reasons: > > > > - it is more meaningful > > > > - we are adding first, second and third reserved fields to > > > > match > > > > the 3 bytes of rsvd0 (patch to come) > > > > > > Sound clear and reasonable. I would like to propose the alignment between rte_flow_field_id and rte_vxlan_hdr: > > > 1. > > > > > > RTE_FLOW_FIELD_VXLAN_RSVD1 ---> RTE_FLOW_FIELD_VXLAN_LAST_RSVD > > > > > > 2. > > > > > > "uint8_t rsvd1" ----> "uint8_t last_rsvd" > > > > We don't change rte_vxlan_hdr, because we avoid breaking compatibility. > > How about to add a new union: > > union { > uint8_t rsvd1; > uint8_t last_rsvd; > } > RTE_FLOW_FIELD_VXLAN_LAST_RSVD will perfectly match the rte_vxlan_hdr definition. It could be a solution, yes, but I don't see it in your v5.