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 0AF8FA034E; Wed, 27 May 2020 14:34:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B3EF81D932; Wed, 27 May 2020 14:34:18 +0200 (CEST) Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) by dpdk.org (Postfix) with ESMTP id DAFF11D91A for ; Wed, 27 May 2020 14:34:16 +0200 (CEST) Received: by mail-il1-f193.google.com with SMTP id h3so1246929ilh.13 for ; Wed, 27 May 2020 05:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mSyM6Xbw972j5SbhAsLNvpphWfFxMQnFKJqXfuDgarE=; b=uoBjx/uV8PoTJED2wp3rxAVYShXmRBRQuAFlW28f9kPQp9Cr7ijq3oj7wUqYd8T3ud MykHUK8HZ89pclXH82JtUnOZKlVOWG+gQLrsjidXnlmjx9Ga15WFMmj6okS3EUmljV+Z lZCtXIy5CT+QyTuW8eTuP2MmZO1qJICrJem/Mga7XRqAKYKIy28wrjjd5kTvHksJRHF8 UX39ZLTaeR0DMkniZDxQs+Ch2Wgj3pnVDwCTZMp7HTk5T9o0F39drtNWDSDHqidpT2oZ WJTf+R+AoSuYtz+yoT27q9Fl2JvEz3FM5V1PrqT95apekX+UeHmd1vPT9d02RJt6vLGB XlJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mSyM6Xbw972j5SbhAsLNvpphWfFxMQnFKJqXfuDgarE=; b=mGOGVKG+2EbqQ6X4uWN+wqoHFYD8eY7MPk8U5HvUDhsmCDgD62x0SyLoHnL5CfmGPS INbMB/3HJoE8eXLFMONfmgKct/LmNtp2FDCPGkh65tjt68+dJxOtTE3ZSK/LDWdLN+yQ FKc4hjr/DO72Te90FiqChPUSQU/1ryn1Y5MJnO2ndzqzRORDW/F+W4FNMxZmxxgtU58O du8UwmwAXZguebd8uq753wRRTBzjA/QU5hNCbVhEt3Mxxz5fux9MEqNnvHtZMzQB1KqP OBLzidnWJ7CSz8XVJ82vpqqlo0DY+Jlh0ktGkpJc67456a8kanxc2fWyEWO1zTHYoOk9 5dMw== X-Gm-Message-State: AOAM533NcxhmnXv38pJw11kZv5ZcnOJyhomBDFwcb8c9q1Mz9Mn5EsCJ PtWpCUaEOnB8z35GwNDFhZpYuPl0v0I9Xs2NhbU= X-Google-Smtp-Source: ABdhPJwTkrWJAItdcda+kuDsJC5bWg4LPUAlU/MVGnJkDnKMPk05DBRQV2+y+BukGl7BtHVvzkiZ3cJyJh2/ay9a1zQ= X-Received: by 2002:a92:8c4a:: with SMTP id o71mr5608445ild.130.1590582855981; Wed, 27 May 2020 05:34:15 -0700 (PDT) MIME-Version: 1.0 References: <20200525212415.3173817-1-thomas@monjalon.net> <2617275.OaBZfIjOFF@thomas> <3071819.TdKep6GQZa@thomas> <20200527122324.GH2554@platinum> In-Reply-To: <20200527122324.GH2554@platinum> From: Jerin Jacob Date: Wed, 27 May 2020 18:04:00 +0530 Message-ID: To: Olivier Matz Cc: Thomas Monjalon , Jerin Jacob , dpdk-dev , David Marchand , Nithin Dabilpuram , Krzysztof Kanas , Andrew Rybchenko , Ferruh Yigit , "Richardson, Bruce" , John McNamara , Marko Kovacevic Content-Type: text/plain; charset="UTF-8" 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 Wed, May 27, 2020 at 5:53 PM Olivier Matz wrote: > > On Wed, May 27, 2020 at 05:37:13PM +0530, Jerin Jacob wrote: > > On Wed, May 27, 2020 at 5:26 PM Thomas Monjalon wrote: > > > > > > 27/05/2020 13:43, Jerin Jacob: > > > > On Wed, May 27, 2020 at 3:21 PM Thomas Monjalon wrote: > > > > > 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? > > > > > > > > IMO, there is a gap. The subject says the rule, but no rule here. > > > > We are just giving some guideline and following info in the patch > > > > given by Olivier is not > > > > expressed if we read the patch. > > > > > > > > " > > > > I don't think we should be too strict: the door remains open for > > > > technical debate and exceptions. > > > > " > > > > > > Indeed, the headline should be > > > mbuf: add guideline for new fields and flags > > > > > > > > > > > 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. > > > > > > > > Yes. The email thread[1] provided all the details. We have optimized > > > > to one bit for this feature. > > > > We are expecting Olivier to comment on the new proposal. > > > > [1] > > > > http://patches.dpdk.org/patch/68733/ > > > > > > > > > Note: I don't have a definitive opinion on it, I need to read it carefully. > > > > > > > > Please read it carefully and please provide any technical opinions if > > > > you have any. > > > > > > > > > > > > > > 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. > > > > > > > > Yes. But I dont think, this patch is not enforcing anything such, > > > > instead it makes it as an open-ended > > > > for more confusion. IMO, if it not black and white then better to not > > > > express the rule. > > > > > > I disagree about "more confusion". > > > > My confusion will clear up if > > 1) s/rule/guide line/ change across the patch > > OK for me, guideline is indeed a better name. > > > 2) Explicit mention of the following or similar sentence. > > it is a guideline and exception is allowed on a case by case using > > technical debate. > > In my opinion, anything written in the documentation is questionable and > discussable (because the code or the environment can change, or because someone > can come with new arguments), and I don't really see the added value to > explicitly say it... or we'll have to say it for every guideline in the > documentation. Is n't source of confusion? in the email we are saying exception is allowed. But we dont want to document it? What is the harm in documenting IF IT IS really allowed it? If it not documented, how someone know what is agreed upon? If the code or environment changes, we can change the patch as well based on everyone's agreement based on the patch review. IMO, What is agreed upon should be documented. > > > > > > > I think the value of this patch is to improve awareness > > > about the need for using dynamic fields and flags. > > > > > > Let's ask other opinions about the added value of this patch. > > > > > >