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 C1F7CA0471 for ; Tue, 16 Jul 2019 16:43:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 551372BC7; Tue, 16 Jul 2019 16:43:58 +0200 (CEST) Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) by dpdk.org (Postfix) with ESMTP id C2DE12BBE for ; Tue, 16 Jul 2019 16:43:56 +0200 (CEST) Received: by mail-pg1-f174.google.com with SMTP id f20so323707pgj.0 for ; Tue, 16 Jul 2019 07:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=wgXymSqxSqtwKE3PXJjeK/UfPJf0lZmSOUhWEpgChTg=; b=BfjHdpqEDKPic2RA96xtYtRfsH7G5AqLtAKPBOMGnO+RxPckGHhbdk1HL72mo0U7Qc vjTE0ynvQtxDWNnvi3ntisQdb7zcnMsK8klTgVQ31jG101ZXGwGNhw+h9W8LKxXUv30E mvjBv/gKv00MpcLHmxRVVFphVrsJx+WkHnvKMegZMsrl+FlrGfQE+G/v3IOxArqN0PoC QpEWqHHw0IZN2wMl8wUr8mNe/xxcxzOPawoYs+MB8CXQj/pH87sdQRfJ6Aqph9hNsotT nZjFBdN1wS0YqqE+kCWrW5+Dn231hA4aZ4H6QoA5JfnmQKeELFVimKM6BOi+wVoCKZ6R G3KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=wgXymSqxSqtwKE3PXJjeK/UfPJf0lZmSOUhWEpgChTg=; b=Y6OFgiCHLFo8/dTPtBw8RfYiFbvJP5rCYwdyXZNxakVlL31noIy6VJ8Dlx1VGkCS/6 cgfjS9xmcTw1hJoGxtGKz/mVWUkShdlw/X1T4QEY9siO3Wq83tGZymFSq5LcRPsENL+7 k5k1ivWIdB0TOGB1M+lgBISdwUpWhH1RY/BO1h+yMCFuFBx+yyh/oFgdlc6+5D9cpM0K f032XLCuSzK5S/5hTgZOnZ2QfKGmQX0QZ8nxp+R5WIBccd+mi2S6F8gKMwHNkywYr1YB fNtPaxAd3NJhIRAviFz5IY0r2HLHR/0pNgYbVm3m2Dcg6KK6JyJH9sZFX8Mh6P0gbcWn paXQ== X-Gm-Message-State: APjAAAW0Lo4QcLPNNV50Ol94grGom8ascSD4aXMUPHw5lTNMq5briUFL vnOszeekhMG0ZMio01Rog1k= X-Google-Smtp-Source: APXvYqzV1Bf+K6gucUBTbl1h+81gCImeIvt8ypnyulfRiMf6XHNPAopfv2Qe/hJQ4ZmVbDfjJnxZHg== X-Received: by 2002:a63:fc52:: with SMTP id r18mr34130952pgk.378.1563288235649; Tue, 16 Jul 2019 07:43:55 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id 185sm21529636pfd.125.2019.07.16.07.43.55 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 16 Jul 2019 07:43:55 -0700 (PDT) Date: Tue, 16 Jul 2019 07:43:53 -0700 From: Stephen Hemminger To: Olivier Matz Cc: Jerin Jacob Kollanukkaran , "dev@dpdk.org" Message-ID: <20190716074353.66dc910f@hermes.lan> In-Reply-To: <20190716093950.kb7w54l2zs3fi7ws@platinum> References: <20190710092907.5565-1-olivier.matz@6wind.com> <20190710104917.73bc9201@hermes.lan> <20190711073638.64ljp526pengnwga@glumotte.dev.6wind.com> <20190716093950.kb7w54l2zs3fi7ws@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Tue, 16 Jul 2019 11:39:50 +0200 Olivier Matz wrote: > 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. > Applications are already using userdata reusing that in a driver would cause a worse disaster than breaking ABI.