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 F34D6429E1; Tue, 25 Apr 2023 00:41:52 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C3EF340A7E; Tue, 25 Apr 2023 00:41:52 +0200 (CEST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id B8C3D400D7; Tue, 25 Apr 2023 00:41:50 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 3D9FE32005BC; Mon, 24 Apr 2023 18:41:49 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 24 Apr 2023 18:41:49 -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=fm3; t= 1682376108; x=1682462508; bh=QKCcJgnVYRGSYO6yCmNEDn1q+FGzD8nwqbS CaHplT0E=; b=vRpkvjMuoulVAsIs1O7ST1nOiFrNE6wtiG1ocDX++1IDd5aJChd LWd24HKLKxthKukSfHPKetPPVvYzRfsN1C2lB1ZOfwGSGChhH1NC/LrJL69Rr2oE tUonnD3nGkMG3rQ0tV+lxiOIcidYiGvaBBa3Hg4PREW6NK352rxi3cDv0Lsie7gG 7GqW3zNOXVhSMnmqGOat/broV2nsOhY5TVpPZXs3k/SBUUQxxZuhmVdr15uuaeM4 b3oGk0jiiLZkj8k4lPXS998JVnSOsh0qXkAJhXthRAn0n70mptgxlkxtfZokLGRa sHtbdkYPg9ZZaQlHBTadJr9exGEiyPhYfvg== 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=fm3; t= 1682376108; x=1682462508; bh=QKCcJgnVYRGSYO6yCmNEDn1q+FGzD8nwqbS CaHplT0E=; b=af5TSSSmo9PROeCF7Hwu9U8vo79wdysD4QNS2yTyvFg9zZo7sH/ OsDpY+odWWdryyuC5Fj2nPX+aFPbiPERrlHo8Yl56Xm4sPnhfzUIt6bCtdrWiTgC lNqUUmyJWpkP5pWNNdEbCmQoq9fCZpXRzWdNn2e6hVEZy+LjK5HxFR30PA6FA2Cx Ig8SZ3bBMOvDV/RsOK0bRZBVfkv6ru47IX/Uei/1G0jMfurqPayvkJZX6pl+wcKl KuX2mSoo/W0OBaZ1tiIILUAybiKWc4Z62q5+z4wKnh0XQoHtpmeVLvl81fmZ0g96 6L+cHH1A/RX4GxYJKa4QZzO4suqWuRT11LQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeduuddgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeegtddtleejjeegffekkeektdejvedtheevtdekiedvueeuvdei uddvleevjeeujeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 24 Apr 2023 18:41:47 -0400 (EDT) From: Thomas Monjalon To: Stephen Hemminger , Jerin Jacob Cc: 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, 25 Apr 2023 00:41:45 +0200 Message-ID: <5925463.UjTJXf6HLC@thomas> In-Reply-To: References: <20230309085645.1630826-1-ndabilpuram@marvell.com> <20230411110553.25f7c038@hermes.local> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 18/04/2023 10:33, Jerin Jacob: > On Tue, Apr 11, 2023 at 11:36=E2=80=AFPM Stephen Hemminger > wrote: > > > > On Tue, 11 Apr 2023 15:34:07 +0530 > > Nithin Dabilpuram wrote: > > > > > diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h > > > index 4bacf9fcd9..866cd4e8ee 100644 > > > --- a/lib/security/rte_security.h > > > +++ b/lib/security/rte_security.h > > > @@ -275,6 +275,17 @@ struct rte_security_ipsec_sa_options { > > > */ > > > uint32_t ip_reassembly_en : 1; > > > > > > + /** Enable out of place processing on inline inbound packets. > > > + * > > > + * * 1: Enable driver to perform Out-of-place(OOP) processing f= or this inline > > > + * inbound SA if supported by driver. PMD need to register= mbuf > > > + * dynamic field using rte_security_oop_dynfield_register() > > > + * and security session creation would fail if dynfield is= not > > > + * registered successfully. > > > + * * 0: Disable OOP processing for this session (default). > > > + */ > > > + 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 o= ption. > > > */ > > > - 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. >=20 > Yes. I think, we need to enforce to have _init functions for the > structures which is using reserved filed. >=20 > 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: =2D more #ifdef clutter =2D 2 binary versions to test =2D CI and checks must handle RTE_NEXT_ABI version