From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 895A2A32A2 for ; Thu, 24 Oct 2019 18:40:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8D79F1EB81; Thu, 24 Oct 2019 18:40:40 +0200 (CEST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id D07161EB7F for ; Thu, 24 Oct 2019 18:40:39 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id D60B570DC; Thu, 24 Oct 2019 12:40:37 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 24 Oct 2019 12:40:37 -0400 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=mesmtp; bh=OJK5TAfUe+QMqTq5yAYFEORO47YDj23pEhZNgY5uFbY=; b=ZRVMtk1uiYZ2 XJ99KDCKOOmz+C3sqpzxIy2zkGjOiZfHwWV4ocJubnEq3b4/4pORzgeQFk2P4Ayx dtdWmweZDy0m5HeL+KyCqXE8ebOPD1mwKTRPdNtUtrIX1+XxD0NQF70DWvlfB6D/ 1MYzW3L+BvVBcXLAf5R2WpDFMP6CfKQ= 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=OJK5TAfUe+QMqTq5yAYFEORO47YDj23pEhZNgY5uF bY=; b=blEQvlOCBptPD5Yu0BtqLswazGiAe5Feeccm3IOAltt5kZRPHsjd4DkdX Od/DxO2kbUH4moV4DXNlKNRANDYmrgP5m5JbLrcN7cbtTmzuiBBg0/3WDri/QrwW gqCvRcYopuRV99b9tDo4XxU3tHlWH93R855MR4fNlBngClVHQ+Z1wGtFxdfHH+tH c5Jwr+VUilJAr+gTmq0iW8lsYVOATrT3iC4QEKX0MdLRZdhE9g3pX3tpsZZsrkvz jk5VuqJuZE/qRjAmDvAcx06gmavyzU0I+sGtsHK5HCvWijHXo8of2CReWPR/dD+F EPu00IqC7pbLz1cDQEZSnwBaB1ACQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrledugddutdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedu X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 0DAA9D60065; Thu, 24 Oct 2019 12:40:34 -0400 (EDT) From: Thomas Monjalon To: Olivier Matz Cc: dev@dpdk.org, Andrew Rybchenko , Bruce Richardson , "Wang, Haiyue" , Jerin Jacob Kollanukkaran , "Wiles, Keith" , "Ananyev, Konstantin" , Morten =?ISO-8859-1?Q?Br=F8rup?= , Shahaf Shuler , Stephen Hemminger , Slava Ovsiienko Date: Thu, 24 Oct 2019 18:40:34 +0200 Message-ID: <1692889.GNPo5m3yn4@xps> In-Reply-To: <20191024081337.26411-1-olivier.matz@6wind.com> References: <20190710092907.5565-1-olivier.matz@6wind.com> <20191024081337.26411-1-olivier.matz@6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3] mbuf: support dynamic fields and flags X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 24/10/2019 10:13, Olivier Matz: > Many features require to store data inside the mbuf. As the room in mbuf > structure is limited, it is not possible to have a field for each > feature. Also, changing fields in the mbuf structure can break the API > or ABI. > > This commit addresses these issues, by enabling the dynamic registration > of fields or flags: > > - a dynamic field is a named area in the rte_mbuf structure, with a > given size (>= 1 byte) and alignment constraint. > - a dynamic flag is a named bit in the rte_mbuf structure. > > The typical use case is a PMD that registers space for an offload > feature, when the application requests to enable this feature. As > the space in mbuf is limited, the space should only be reserved if it > is going to be used (i.e when the application explicitly asks for it). > > The registration can be done at any moment, but it is not possible > to unregister fields or flags. > > Signed-off-by: Olivier Matz > Acked-by: Thomas Monjalon > Acked-by: Konstantin Ananyev I feel I could merge this patch. I will hold on for few hours and will proceed.