From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63E37C77B7A for ; Tue, 30 May 2023 13:51:45 +0000 (UTC) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 30CC740A82; Tue, 30 May 2023 15:51:44 +0200 (CEST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by mails.dpdk.org (Postfix) with ESMTP id F1DAF406BC; Tue, 30 May 2023 15:51:41 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 94BAB320046F; Tue, 30 May 2023 09:51:40 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 30 May 2023 09:51:41 -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= 1685454700; x=1685541100; bh=FTpO7Urrlrik/4z8NYBxwjE699JIKN8lOys 8Tf3+r5M=; b=yjIQIR4lymkEx77spkoVhZvAIPIByG/llrlVQTY0DWgprZpYt4Y +kBdQgqynW7PfNq9buUOZchvxgYvenQinHT2UB0E+OIOMM3e8MASxYUHDsutbRmZ Tfu3LogKKI4ByfKoAG5TTKrVjK6kRmc4q6qBd7j97GA7JoRgr6RtA5xGlwwq7x/G U1TuMeivrk+88WPTfS99XjJKbiDFvyMYVAN5Nnau/Xx9KfNe8zNst1d6uKNc0t4l T/INHfBoRKpfSkyZ/8aIokNVYh4LdCcVxFPwLxtsb8ivJmKhio22qCMm19CjzdQI rLUfaXwGjHdNWf3aFAmJuVWmvyKItHofvmg== 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= 1685454700; x=1685541100; bh=FTpO7Urrlrik/4z8NYBxwjE699JIKN8lOys 8Tf3+r5M=; b=LItFD8o5syhqm5z49lrUh2H3xQNsGEt05nDkdVnBPCeRzCRqipE xoHLMJf0cDO6lr5WP6hV9whBEqCR+LIZBHv9wFlszsK/oyZ5Kr/JV9BXe2JSzjAZ 7xYYfyMczaUqJiXNTUBzZQxc6IZCbFE4ZHN9JRiQVwAU9rD279H6X8Nx9GLwE5/n +J5f4uF6ibN9eocPOQ/x24Nxslg4kVqg4NuFqHJl62cEB7V/b+tQWtbxW5f91MGe HwnLs6pXWjLC3MQbGi1PCQ8DgquCvrTeXu0tqUfdIyav7JY7EAMQsKn+/dIK7l2U ualtjEtExIzDnqItLlH7IrHkpscwyC4ddvw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeekjedgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 30 May 2023 09:51:38 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: Stephen Hemminger , Nithin Dabilpuram , Akhil Goyal , jerinj@marvell.com, dev@dpdk.org, Morten =?ISO-8859-1?Q?Br=F8rup?= , techboard@dpdk.org Subject: Re: [PATCH 1/3] security: introduce out of place support for inline ingress Date: Tue, 30 May 2023 15:51:36 +0200 Message-ID: <1887881.GKX7oQKdZx@thomas> In-Reply-To: References: <20230309085645.1630826-1-ndabilpuram@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 30/05/2023 11:23, Jerin Jacob: > > > > > > + */ > > > > > > + uint32_t ingress_oop : 1; > > > > > > + > > > > > > /** Reserved bit fields for future extension > > > > > > * > > > > > > * User should ensure reserved_opts is cleared as it may change in > > > > > > @@ -282,7 +293,7 @@ struct rte_security_ipsec_sa_options { > > > > > > * > > > > > > * Note: Reduce number of bits in reserved_opts for every new option. > > > > > > */ > > > > > > - uint32_t reserved_opts : 17; > > > > > > + uint32_t reserved_opts : 16; > > > > > > }; > > > > > > > > > > NAK > > > > > Let me repeat the reserved bit rant. YAGNI > > > > > > > > > > Reserved space is not usable without ABI breakage unless the existing > > > > > code enforces that reserved space has to be zero. > > > > > > > > > > Just saying "User should ensure reserved_opts is cleared" is not enough. > > > > > > > > Yes. I think, we need to enforce to have _init functions for the > > > > structures which is using reserved filed. > > > > > > > > On the same note on YAGNI, I am wondering why NOT introduce > > > > RTE_NEXT_ABI marco kind of scheme to compile out ABI breaking changes. > > > > By keeping RTE_NEXT_ABI disable by default, enable explicitly if user > > > > wants it to avoid waiting for one year any ABI breaking changes. > > > > There are a lot of "fixed appliance" customers (not OS distribution > > > > driven customer) they are willing to recompile DPDK for new feature. > > > > What we are loosing with this scheme? > > > > > > RTE_NEXT_ABI is described in the ABI policy. > > > We are not doing it currently, but I think we could > > > when it is not too much complicate in the code. > > > > > > The only problems I see are: > > > - more #ifdef clutter > > > - 2 binary versions to test > > > - CI and checks must handle RTE_NEXT_ABI version > > > > I think, we have two buckets of ABI breakages via RTE_NEXT_ABI > > > > 1) Changes that introduces compilation failures like adding new > > argument to API or change API name etc > > 2) Structure size change which won't affect the compilation but breaks > > the ABI for shared library usage. > > > > I think, (1) is very distributive, and I don't see recently such > > changes. I think, we should avoid (1) for non XX.11 releases.(or two > > or three-year cycles if we decide that path) > > > > The (2) comes are very common due to the fact HW features are > > evolving. I think, to address the (2), we have two options > > a) Have reserved fields and have _init() function to initialize the structures > > b) Follow YAGNI style and introduce RTE_NEXT_ABI for structure size change. > > > > The above concerns[1] can greatly reduce with option b OR option a. > > > > [1] > > 1) more #ifdef clutter > > For option (a) this is not needed or option (b) the clutter will be > > limited, it will be around structure which add the new filed and > > around the FULL block where new functions are added (not inside the > > functions) > > > > 2) 2 binary versions to test > > For option (a) this is not needed, for option (b) it is limited as for > > new features only one needs to test another binary (rather than NOT > > adding a new feature). > > > > 3) CI and checks must handle RTE_NEXT_ABI version > > > > I think, it is cheap to add this, at least for compilation test. > > > > IMO, We need to change the API break release to 3 year kind of time > > frame to have very good end user experience > > and allow ABI related change to get in every release and force > > _rebuild_ shared objects in major LTS release. > > > > I think, in this major LTS version(23.11) if we can decide (a) vs (b) > > then we can align the code accordingly . e.s.p for (a) we need to add > > _init() functions. > > > > Thoughts? > > Not much input from mailing list. Can we discuss this next TB meeting? > Especially how to align with next LTS release on > -YAGNI vs reserved fileds with init() > -What it takes to Extend the API breaking release more than a year as > first step. Yes I agree it should be discussed interactively in techboard meeting.