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 7A50A41B8D; Tue, 31 Jan 2023 10:42:42 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0E6E340DFB; Tue, 31 Jan 2023 10:42:42 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 6E4924067B for ; Tue, 31 Jan 2023 10:42:40 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id BD17E5C00E6; Tue, 31 Jan 2023 04:42:39 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 31 Jan 2023 04:42:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding: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=fm3; t=1675158159; x= 1675244559; bh=XzOALmiL17VQOx5/qT3zFZOWvSxFGE4gn7a6ZoMuU0k=; b=d IydWflMEcTKVqxWk8ZWm/F8UZl2kNH24rR4nS5vNvJzvDhAFAy3fXYpcZmi67bYp Utl24xkGABVcE0g5yxkUSDza+WxVwuaPvyM+SiIj+QhQdXnA8p1B8t+285dk5Hm/ L+q1drJwKhaCLnl5YwvgX2mYiNGNzGqdl2spxb7sT02INcJ1JlltkPttQHP+cwcl r8GhxVr16BrprAbNODeh7rrTKGjkcnN4I7KfQwqezX5PvO4p5Pz9vBeBphIas0G3 lj43NgBXTMf5cZdUDclZu3nYWtAG6ZS/mjFDpYxxU2FAfbU0VEKKlguibdYibb+2 D3ZA9jsYkIwIWaUIJq0hA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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=fm3; t=1675158159; x= 1675244559; bh=XzOALmiL17VQOx5/qT3zFZOWvSxFGE4gn7a6ZoMuU0k=; b=B +gvDFXaRYVAe0ojv90JP9/RQtocXYDQDW+JQOfm25m0Bo9gLJX6wdegnFd7/hi3G lgDXbLGn2ZPHMjR4a81JZo39v3rJdMj4GKD5asJRmXmXK8OQQQWXAE9v5dWMM5Tw 7jOWRJlE1BMuf5ZEHw994Y0Du43Rd5Gx0Urhn1ydPmQDk6rk2pynXs8TgP0jj6Ad T53L4KpaJHcahQ0t9gkoUlHRjqJDbBSHt0l12GFh6Y5HWmm1kXGZvlK9srWamUWg wEKn9JAUWbjb0bo10kADRh9qFiIAu/KC5KygWhLDp09l3Jzi99ZCFBIxYmLwjXGu 1g1glZGomWijz5ml/SH+Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudefgedgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 31 Jan 2023 04:42:37 -0500 (EST) From: Thomas Monjalon To: Stephen Hemminger , Andrew Rybchenko , Rongwei Liu Cc: Matan Azrad , Slava Ovsiienko , Ori Kam , Aman Singh , Yuying Zhang , Ferruh Yigit , Olivier Matz , "dev@dpdk.org" , Raslan Darawsheh Subject: Re: [PATCH v3 1/8] ethdev: add IPv6 routing extension header definition Date: Tue, 31 Jan 2023 10:42:35 +0100 Message-ID: <13191775.uLZWGnKmhe@thomas> In-Reply-To: References: <5da6632a-0976-dc1f-facb-f778c8aad8e6@oktetlabs.ru> 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 31/01/2023 10:18, Rongwei Liu: > From: Rongwei Liu > > From: Stephen Hemminger > > > Rongwei Liu wrote: > > > > > > > +/** > > > > + * @warning > > > > + * @b EXPERIMENTAL: this structure may change without prior notice > > > > + * > > > > + * RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT. > > > > + * > > > > + * Matches an IPv6 routing extension header. > > > > + */ > > > > +struct rte_flow_item_ipv6_routing_ext { > > > > + struct rte_ipv6_routing_ext hdr; }; > > > > > > The problem with nesting a variable length structure inside another > > > structure is not allowed. > > > > > > The issue is that the applicaiton would have to pass a variable length > > > structure in for the flow definition. The flow item is variable length > > > for this type? all the others are fixed length. > > > > > Yeah, segments_left is uint8 per definition. RFC doesn't set an upper limitation. > > It stands for intermediate routing nodes between src and dst nodes. > > > One option would be to get rid of the wrapper structure. > > Yeah, it works. @Andrew Rybchenko Can you share your preference here? > I want to propose "moving flex array" out of the "struct rte_ipv6_routing_ext " and present in " struct rte_flow_item_ipv6_routing_ext" > Sounds good? For Geneve, we have defined a separate flow item: rte_flow_item_geneve_opt. I'm OK to move the optional fields in the flow item. This is what you did in v4.