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 9A525A04A4; Wed, 19 Jan 2022 11:01:24 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 443B0410F4; Wed, 19 Jan 2022 11:01:24 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 440EA4013F for ; Wed, 19 Jan 2022 11:01:23 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id AECA55C0170; Wed, 19 Jan 2022 05:01:21 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 19 Jan 2022 05:01:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= ZIpDH1AARylJsuuOtuOWXVhZdx66anRSRoBjiCFaBl0=; b=IRFuL13a+qgQMHJ0 syAetcN5hTw4Ngqa17tHnDYYg3vBvxa97Ycl7QYo4A8Poiv22D4g+KhYcwoFPjqs HM8Zbehz97l6EI0xvcnB7tbv7s+yU+iNl3tkcTyOd5DMFnG31H24p7wNK6Eq6m/G p/6ezSGHBIbxlIhrnAr/eSMFDA5Hls6Ikw8oX90jas9iSgf6a6NYrrmPTMki7f5D iXdS/mLRT0WzjIa6s/Bsy7KK5q1Vk18G1QpVO0cjrGXKEvpJz0HC1WANYigFq07i qlg0kLSneVOkxXcyrunX4gDBWhnj+8OnyVtSaE9t0oZnTfAuhnaVu0YM0pCaf+NX oWX5aw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=ZIpDH1AARylJsuuOtuOWXVhZdx66anRSRoBjiCFaB l0=; b=SDXPmvK/Q3EaKsfIZ4l1XwL+QIQ+kJ9B6vHzrBwsLNoR99UhgXCLkd+7g zKMZI9l5qFgF52kZNc9jO1vLoVqP7PmNFm0QhgVcHPGVdGvG3xk7rtAXu3Xeu1BA GvzOWWTgrIemBM3KGMDMTRuaMa1dGepg9vJ1ejwdw9/TgNJSmq+HCYhChwXRpgty 7+o/9vNJ4AEQiwF9jvpjrrdwoSjoIgpuEHQmL4i+ts51knkSU+w7hk57nm9lgFMs 5NEYD3GSm88An3LR2ZBCobJKUnxo8MnxNYcMDGTpq9GSSlIaw9VEjwUUmqyp8iNF nxa99aaQOpiI9h5regsjwGvZz1iDQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudehgdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 19 Jan 2022 05:01:20 -0500 (EST) From: Thomas Monjalon To: Sean Zhang , orika@nvidia.com, matan@nvidia.com, Ferruh Yigit Cc: Andrew Rybchenko , dev@dpdk.org Subject: Re: [RFC 1/3] ethdev: support GRE optional fields Date: Wed, 19 Jan 2022 11:01:19 +0100 Message-ID: <2037437.VsPgYW4pTa@thomas> In-Reply-To: <002b1f85-0871-a02f-0345-1b19d722762a@intel.com> References: <20211230030817.15264-1-xiazhang@nvidia.com> <20211230030817.15264-2-xiazhang@nvidia.com> <002b1f85-0871-a02f-0345-1b19d722762a@intel.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/01/2022 10:53, Ferruh Yigit: > On 12/30/2021 3:08 AM, Sean Zhang wrote: > > --- a/lib/ethdev/rte_flow.h > > +++ b/lib/ethdev/rte_flow.h > > /** > > + * RTE_FLOW_ITEM_TYPE_GRE_OPTION. > > + * > > + * Matches GRE optional fields in header. > > + */ > > +struct rte_gre_hdr_option { > > + rte_be16_t checksum; > > + rte_be32_t key; > > + rte_be32_t sequence; > > +}; > > + > > Hi Ori, Andrew, > > The decision was to have protocol structs in the net library and flow structs > use from there, wasn't it? > (Btw, a deprecation notice is still pending to clear some existing ones) > > So for the GRE optional fields, what about having a struct in the 'rte_gre.h'? > (Also perhaps an GRE extended protocol header can be defined combining > 'rte_gre_hdr' and optional fields struct.) > Later flow API struct can embed that struct. +1 for using librte_net. This addition in rte_flow looks to be a mistake. Please fix in the next version.