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 4BC18A04A4; Wed, 27 May 2020 11:51:27 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0575C1D5F9; Wed, 27 May 2020 11:51:26 +0200 (CEST) Received: from wnew2-smtp.messagingengine.com (wnew2-smtp.messagingengine.com [64.147.123.27]) by dpdk.org (Postfix) with ESMTP id BAD101D5EE for ; Wed, 27 May 2020 11:51:24 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.west.internal (Postfix) with ESMTP id 5FD3811C4; Wed, 27 May 2020 05:51:22 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 27 May 2020 05:51:23 -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=fm1; bh= 4Q0TtgjbEHOBbMb+/YyEtjR3jHRtyS93kjl8QNSRR4M=; b=w33kToWCGCTxFLiu TolAQOABTRGVa6noeidMEooj7UcQ5aaBY0EKu6vlQH36iw8FF3MJmSMB3ZDyy4iu 8VDJQ47wMKYWyxGQJ6iEpQAatO36XmyPQWa6dvr+NCDoAPbd07XCfDQWgIEbd2Ct IwMlmcukPoH9NvfT/qZ13/1tU8QL1WVkPpuJJlOdHqbretV4YETkBkwf8fusSroo nQNDO1wbJtohiTi5R1vDWfnoSqKEkTdzCL8u6p9XO0n2GElGmnh8QNA59drOzbUd 01k5zCfUZeyydaag6hhXEQ3ARdD/ZzOO1PJtTY2fyMH/9kyAyLwa1vRr/o3H91/F Eur4aQ== 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=fm2; bh=4Q0TtgjbEHOBbMb+/YyEtjR3jHRtyS93kjl8QNSRR 4M=; b=rKZt543kklRS9ISXh9VPp/zZKVI6M98bWsyOA+f3b+UN7gLkjQspmm0p/ 9L7ygNHFeY6Ec7heTZbwp3HjlvqGb2cRK1nmr3rtP04knv0QEPfIwLOhS4+JiQOw NpG0kP6hHP0636ufXWmkD/FZMOkG2rVpmDhdIc3Av80PCK0Z5DQqZK5a8ukPwOE9 sE9pysoqgqOb29OMeA7O2e8zd8p2UEVbYFwR0/9TiLTmKdhT9C/fX9Q1rgydK5KW UIw/Sp3Gpj+orDhN9D30KnX0wh4Z579mmaJm+Ldg2i0v0BoUoJ2biviThK7jRXLk v1D1JbYfC/6xrpYDKHb+RbGsRRPxw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvgedgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepffdvffejueetleefieeludduuefgteejleevfeekjeefieegheet ffdvkeefgedunecuffhomhgrihhnpeguphgukhdrohhrghenucfkphepjeejrddufeegrd dvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth 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 DD8C83280063; Wed, 27 May 2020 05:51:19 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob , Jerin Jacob Cc: Olivier Matz , dev@dpdk.org, dpdk-dev , David Marchand , Nithin Dabilpuram , Krzysztof Kanas , Andrew Rybchenko , Ferruh Yigit , "Richardson, Bruce" , John McNamara , Marko Kovacevic Date: Wed, 27 May 2020 11:51:18 +0200 Message-ID: <2617275.OaBZfIjOFF@thomas> In-Reply-To: References: <20200525212415.3173817-1-thomas@monjalon.net> <20200527070958.GE2554@platinum> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 27/05/2020 09:31, Jerin Jacob: > On Wed, May 27, 2020 at 12:39 PM Olivier Matz wrote: > > 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: > > > > 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 > > > > > > +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. > > I don't think, we need to anticipate all the criteria in the documentation. > At least ONE should be given as an example of an exception. I think it is too early to be more specific in the guidelines. Do we agree this patch is a first good step in the documentation? We can extend the guidelines a bit later after having some discussions on specific cases, and probably in the techboard too. > I would say, > a) If a feature takes only one bit and its part of normative API spec > and it used in fastpath we should consider the static scheme. > b) Adding an exception to the existing list needs approval at least > from three maintainers > > For me, it is a very legitimate case to have support for > http://patches.dpdk.org/patch/68733/ to the static scheme > as it takes 1 bit for a feature and it is part of the normative spec. > I don't get in explanation in the ml, why > we can not make it as the static scheme for this case. We can continue discussion about this specific case in the right thread. Note: I don't have a definitive opinion on it, I need to read it carefully. > My worry is, if we are keeping as open-ended means, we are giving room > for the disparity among the vendors/feature > as I dont think, There is use case where dynamic scheme can not be > used as a replacement > for static other than performance hit.(Could think of any use case?) > So open ended boils down to preference to specific feature/vendor. I > think,that path should be avoided. Of course all rules and decisions have to be fair. It's not even a question.