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 3821CA32A8 for ; Sat, 26 Oct 2019 19:04:33 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D25E61BF6D; Sat, 26 Oct 2019 19:04:31 +0200 (CEST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by dpdk.org (Postfix) with ESMTP id BB5C91BF6C for ; Sat, 26 Oct 2019 19:04:29 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id CCC845A1C; Sat, 26 Oct 2019 13:04:28 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sat, 26 Oct 2019 13:04:28 -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=NszgmWYFso8GwCvWnxlcSILutW6EdgcpRIQmdkjcqUs=; b=ARJTDJcVvJ2j ffARsxnidZYMCikWjyndAnKrPcMDBEyABp/SwUvr7robuO7MnEH7+SD7iz1uTRAy Rx+zf3fENac6HC1wD9vG7+Gk62csZmKlvjLYsJ9B6OzRazDlesETA+teeddw6PbQ 8VoEPumxzLJtz3r6toD14wLcsM3i8QI= 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=NszgmWYFso8GwCvWnxlcSILutW6EdgcpRIQmdkjcq Us=; b=CfA6y+bArUkw9NL+4IPL+BE2O8v205BvFBrD+UInuHi8N10jsIXE88DJN v5yQyUj1fVZ+F5BO9WiFR7ZAYB9hGDbfDkN+AWvXv7KhGn7OwTnxCujy9LmHnuWw 03jl+y3BOPffGhQCHQGyjHTOVeEk+SrhEAYA+G+1KYDbscJSXXh6QSpjwFGkiOG1 jK6JYemS7sk1wdYQrEFAoei9JEjlF8dBHT4jBrYwCC0/XmD7i9tugl4UzdNqZfZz xqZpKTOgDvTyTNyOkNf9+7AuqIMqeoE5Z6aiYbcdmn9iBofjB0LzR6n+FG84yT2/ marC2FGx0w1zp0Yv9aD+38RoqZmwA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrleehgdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt 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 46D75D6005A; Sat, 26 Oct 2019 13:04:26 -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: Sat, 26 Oct 2019 19:04:25 +0200 Message-ID: <43670524.kXpPSqs3L3@xps> In-Reply-To: <20191026123902.417-1-olivier.matz@6wind.com> References: <20190710092907.5565-1-olivier.matz@6wind.com> <20191026123902.417-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 v4] 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" 26/10/2019 14:39, 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 Applied, thanks, this is a new major feature.