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 75DF7A0471 for ; Tue, 16 Jul 2019 11:39:55 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D76213423; Tue, 16 Jul 2019 11:39:54 +0200 (CEST) Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id A03A8324D for ; Tue, 16 Jul 2019 11:39:53 +0200 (CEST) Received: from lfbn-lil-1-176-160.w90-45.abo.wanadoo.fr ([90.45.26.160] helo=droids-corp.org) by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hnJzC-00026V-5w; Tue, 16 Jul 2019 11:43:03 +0200 Received: by droids-corp.org (sSMTP sendmail emulation); Tue, 16 Jul 2019 11:39:50 +0200 Date: Tue, 16 Jul 2019 11:39:50 +0200 From: Olivier Matz To: Jerin Jacob Kollanukkaran Cc: Stephen Hemminger , "dev@dpdk.org" Message-ID: <20190716093950.kb7w54l2zs3fi7ws@platinum> References: <20190710092907.5565-1-olivier.matz@6wind.com> <20190710104917.73bc9201@hermes.lan> <20190711073638.64ljp526pengnwga@glumotte.dev.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Subject: Re: [dpdk-dev] [RFC] 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" On Fri, Jul 12, 2019 at 12:23:19PM +0000, Jerin Jacob Kollanukkaran wrote: > > -----Original Message----- > > From: dev On Behalf Of Olivier Matz > > Sent: Thursday, July 11, 2019 1:07 PM > > To: Stephen Hemminger > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags > > > > On Wed, Jul 10, 2019 at 10:49:17AM -0700, Stephen Hemminger wrote: > > > On Wed, 10 Jul 2019 11:29:07 +0200 > > > Olivier Matz wrote: > > > > > > > /** > > > > * Indicate that the metadata field in the mbuf is in use. > > > > @@ -738,6 +741,8 @@ struct rte_mbuf { > > > > */ > > > > struct rte_mbuf_ext_shared_info *shinfo; > > > > > > > > + uint64_t dynfield1; /**< Reserved for dynamic fields. */ > > > > + uint64_t dynfield2; /**< Reserved for dynamic fields. */ > > Since the mbuf size is fixed, What is the downside of union scheme[1] vs upside of proposed scheme > > [1] Example like: > RTE_STD_C11 > union { > void *userdata; /**< Can be used for external metadata */ > uint64_t udata64; /**< Allow 8-byte userdata on 32-bit */ > }; In the particular case of userdata, the union is not an issue, it just means that there are several ways to represent the same data. If needed, it is possible to register a union as a dynamic field. In other case, like m->hash, having a union makes it impossible to use several features of the union at the same time. This would be solved by dynamic fields. > # The fields like mbuf: hash.usr, used in variety of use case together > Like libraries like distributor() and Eventdev using it. If we switch > to dynamic mbuf scheme, We wil take those field using rte_mbuf_dynfield_register() > on library init? If we decide that these fields must be converted to a dynamic field, yes, each library/application will call rte_mbuf_dynfield_register(). > # I see an upside of dynamic mbuf if we can add rte_mbuf_dynfield_unregister API. > But can we ever do that? Because it will be complex if we need introduce notification mechanism etc. An unregister mechanism seems hard to implement, or we can leave the hard part to the user: either ensure that no mbuf is in use anywhere, or that removing the dynamic field won't have any impact. But I'd prefer not introducing an unregistration function until we have a real use-case for it. > # In the real world use case, if with union scheme, fastpath API can simply deference > specific element (say mbuf->fieldx). With dynamic scheme, the offset need to store > in some other data structure and de reference in fastpath before assessing the interested field. > Right? Yes, with dynamic fields, the offset is stored in a variable. A global variable (static to the file or module using it) does the job. This may have a small performance impact.