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 6A4FEA32A1 for ; Thu, 24 Oct 2019 09:07:36 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 01F0B1C010; Thu, 24 Oct 2019 09:07:36 +0200 (CEST) Received: from proxy.6wind.com (host.76.145.23.62.rev.coltfrance.com [62.23.145.76]) by dpdk.org (Postfix) with ESMTP id 392CD1C00E for ; Thu, 24 Oct 2019 09:07:34 +0200 (CEST) Received: from glumotte.dev.6wind.com (unknown [10.16.0.195]) by proxy.6wind.com (Postfix) with ESMTP id 15978335C1D; Thu, 24 Oct 2019 09:07:34 +0200 (CEST) Date: Thu, 24 Oct 2019 09:07:34 +0200 From: Olivier Matz To: Shahaf Shuler Cc: "dev@dpdk.org" , Andrew Rybchenko , Bruce Richardson , "Wang, Haiyue" , Jerin Jacob Kollanukkaran , "Wiles, Keith" , "Ananyev, Konstantin" , Morten =?iso-8859-1?Q?Br=F8rup?= , Stephen Hemminger , Thomas Monjalon Message-ID: <20191024070734.GP25286@glumotte.dev.6wind.com> References: <20190710092907.5565-1-olivier.matz@6wind.com> <20191017144219.32708-1-olivier.matz@6wind.com> <20191023133335.GM25286@glumotte.dev.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH v2] 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" Hi, On Thu, Oct 24, 2019 at 04:54:20AM +0000, Shahaf Shuler wrote: > Wednesday, October 23, 2019 4:34 PM, Olivier Matz: > > Subject: Re: [dpdk-dev] [PATCH v2] mbuf: support dynamic fields and flags > > > > Hi Shahaf, > > > > On Wed, Oct 23, 2019 at 12:00:30PM +0000, Shahaf Shuler wrote: > > > Hi Olivier, > > > > > > Thursday, October 17, 2019 5:42 PM, Olivier Matz: > > > > Subject: [dpdk-dev] [PATCH v2] mbuf: support dynamic fields and > > > > flags > > > > > > > > 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). > > > > > > According to description, the dynamic field enables custom application and > > supported PMDs to use the dynamic part of the mbuf for their specific > > needs. > > > However the mechanism to report and activate the field/flag registration > > comes from the general OFFLOAD flags. > > > > > > Maybe it will be better to an option to query and select dynamic fields for > > PMD outside of the standard ethdev offload flags? > > > > It is not mandatory to use the ethdev layer to register a dynamic field or flag > > in the mbuf. It is just the typical use case. > > > > It can also be enabled when using a library that have specific needs, for > > instance, you call rte_reorder_init(), and it will register the sequence number > > dynamic field. > > > > An application that requires a specific mbuf field can also do the registration > > by itself. > > > > In other words, when you initialize a subpart that needs a dynamic field or > > flag, you have to do the registration there. > > > > I guess my question mainly targets one of the use cases for dynamic mbuf fields which is vendor specific offloads. > On such case we would like to have dynamic fields/flags negotiated between the application and PMD. > > The question is whether we provide a unified way for application to query PMD specific dynamic fields or we let PMD vendor to implement this handshake as they wish (devargs, through PMD doc, etc..) I have no strong opinion. It can be a PMD-specific API (function or devargs) to enable the feature. The only important thing is to not register the field if it won't be used.