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 39967A04EF; Wed, 27 May 2020 09:10:01 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B55101D666; Wed, 27 May 2020 09:10:00 +0200 (CEST) Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by dpdk.org (Postfix) with ESMTP id A6A571D63F for ; Wed, 27 May 2020 09:09:59 +0200 (CEST) Received: by mail-wr1-f66.google.com with SMTP id x6so9277020wrm.13 for ; Wed, 27 May 2020 00:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=iygJzodDBEJQlTYLN/OypfgGqOkgqoBSTQsrSbl452k=; b=c74nVGMpiuxqtE60ZOu2CDhbKWPG1V3C/6kU1b63sfqui8TxI1kYsl5E/8c6XLQv+k FAkEUC2UKXaRTWwG4O5YZaonIglD8adzEIe2wzZCkYlSsFh/Z1pzPoOzvgoIBHJJll0Q BHUCVpQodjbYCeKhb46gq1iSAR2EGwotb12kYSu55ncoYlBHIftXkgy5FIp9sIkW5oOm WGAWt1Uw3cTTzbQ0iC8ZoVoTRrba3I98auxU1pi+AROaVDNmFAOCSUz7fTKYO4WihuEg l7FJDpt/I3zg8lB021ki8zKnBhCifmjumRHF4itKmwRR0mP1MxA3J47W3Bl5tGWvOBF5 eEJA== 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:references :mime-version:content-disposition:in-reply-to:user-agent; bh=iygJzodDBEJQlTYLN/OypfgGqOkgqoBSTQsrSbl452k=; b=KRU2/DQyG00yUMlZekbZG+nQMu1c4fG+nytMqLKAkj6hZ5kTl2K7357Rmk/6qBK5tv yB93/I1m8tuycs4z0V75Yac8+EopwOOyhMOXB2AEcjzzsf2z04FirZKp1wBsJhCoYHOn gr2zOofK/RgtW/k9MyLb5X9DdHTCkjnM7mQek4EENwqZLN1ycUuYjtTyA9uL65dbUBrb sSJvC7Kq1x0AZO4iMqBMRN7xx/yyRnkhVeg/BUsUgBIUJUj8coG51G+m57lyJYV5EDQj 1G6KDGDEC3oe+2erOoeAgkwXCaeCUMA6AkmB8gV5eCm519DTj9+o1jOqyTMWkx2X4HBt RPCQ== X-Gm-Message-State: AOAM533qcdCx6QkFts1kiPaC3jBgpMOk1mhH0NY34njwVADi9e0/Zyrs UqgolZbnpb2CkTvsVLA6rX+AvQ== X-Google-Smtp-Source: ABdhPJzbIVOnK+kySz/MRCC4FfuPNOIscRc4c03KG/mxTWXOGPqk7aLVSIDjK8uxO8zN7V6IFblR3Q== X-Received: by 2002:a05:6000:1150:: with SMTP id d16mr23356607wrx.197.1590563399339; Wed, 27 May 2020 00:09:59 -0700 (PDT) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id a21sm1780191wmm.7.2020.05.27.00.09.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 May 2020 00:09:58 -0700 (PDT) Date: Wed, 27 May 2020 09:09:58 +0200 From: Olivier Matz To: Jerin Jacob Cc: Thomas Monjalon , dpdk-dev , David Marchand , Jerin Jacob , Nithin Dabilpuram , Krzysztof Kanas , Andrew Rybchenko , Ferruh Yigit , "Richardson, Bruce" , John McNamara , Marko Kovacevic Message-ID: <20200527070958.GE2554@platinum> References: <20200525212415.3173817-1-thomas@monjalon.net> <20200526160626.GD2554@platinum> 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] mbuf: document rule for new 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, May 26, 2020 at 09:59:45PM +0530, Jerin Jacob wrote: > On Tue, May 26, 2020 at 9:36 PM Olivier Matz wrote: > > > > Hi, > > > > On Tue, May 26, 2020 at 01:09:37PM +0530, Jerin Jacob wrote: > > > On Tue, May 26, 2020 at 2:54 AM Thomas Monjalon wrote: > > > > > > > > Since dynamic fields and flags were added in 19.11, > > > > the idea was to use them for new features, not only PMD-specific. > > > > > > > > The rule is made more explicit in doxygen, in the mbuf guide, > > > > and in the contribution design guidelines. > > > > > > > > For more information about the original design, see the presentation > > > > https://www.dpdk.org/wp-content/uploads/sites/35/2019/10/DynamicMbuf.pdf > > > > > > > > Signed-off-by: Thomas Monjalon > > > > --- > > > > doc/guides/contributing/design.rst | 13 +++++++++++++ > > > > doc/guides/prog_guide/mbuf_lib.rst | 23 +++++++++++++++++++++++ > > > > lib/librte_mbuf/rte_mbuf_core.h | 2 ++ > > > > 3 files changed, 38 insertions(+) > > > > > > > > diff --git a/doc/guides/contributing/design.rst b/doc/guides/contributing/design.rst > > > > index d3dd694b65..508115d5bd 100644 > > > > --- a/doc/guides/contributing/design.rst > > > > +++ b/doc/guides/contributing/design.rst > > > > @@ -57,6 +57,19 @@ The following config options can be used: > > > > * ``CONFIG_RTE_EXEC_ENV`` is a string that contains the name of the executive environment. > > > > * ``CONFIG_RTE_EXEC_ENV_FREEBSD`` or ``CONFIG_RTE_EXEC_ENV_LINUX`` are defined only if we are building for this execution environment. > > > > > > > > +Mbuf features > > > > +------------- > > > > + > > > > +The ``rte_mbuf`` structure must be kept small (128 bytes). > > > > + > > > > +In order to add new features without wasting buffer space for unused features, > > > > +some fields and flags can be registered dynamically in a shared area. > > > > > > I think, instead of "can", it should be "must" > > > > > > > +The "dynamic" mbuf area is the default choice for the new features. > > > > In my opinion, Thomas' proposal is correct, with the next sentence > > saying it is the default choice for new features. > > > > Giving guidelines is a good thing (thanks Thomas for documenting it), > > but I don't think we should be too strict: the door remains open for > > technical debate and exceptions. > > If you are open for the exception then it must be mention in what case > the exception is allowed and what are the criteria of the exception? > > For example, Why did n't we choose the following patch as expectation > http://patches.dpdk.org/patch/68733/ even if only one bit used. > > If we are not not defining the criteria, IMO, This patch serve no purpose than > the existing situation. > > Do you think, any case where the dynamic scheme can not be used as a replacement > for static other than performance hit. I don't think it is possible to anticipate all criteria in the documentation. With Thomas' proposal, it gives a direction is and a global view, but it must not completly replace reflection and discussion. Olivier