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 11934A04A4; Wed, 27 May 2020 09:31:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4191C1D63F; Wed, 27 May 2020 09:31:57 +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 670D41D624 for ; Wed, 27 May 2020 09:31:55 +0200 (CEST) Received: by mail-il1-f193.google.com with SMTP id y17so20833221ilg.0 for ; Wed, 27 May 2020 00:31:55 -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=ZaFI8LyNE8TxUHDtXlzpzCVlA82ZieQ8/1+zcxR2eZA=; b=tLyyDKl6OsP1RGqLlUD2g4MET/N2pLJdPSsR+mEUgtBxZR3/wE+k4O8DdjIKCo56xR /OxZzwshv7mMn+iHXUHa303INdN1XK4+rk1gGz5k+BCKZ4e+N0QSVZqNURjeCYiw/T/8 cIwaaW7TArHXSyyBZ//79kJahgalH+3cJxPQy/B6ahlZm8cb7x+5p3u9JYtya/7RZFI8 EppACXxVC++RNocZ6wY5s+yk3sp9OrM2u8gobjyPMp3QeJZtHDh/0fb9+I1+AI3slXpz DLcw9HaRzoxMqpgOk6vaTKR+A7Jb1aU/b56JTwd9VGj5tYoLsQEd6WrrUFsq5besc6wE ziag== 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=ZaFI8LyNE8TxUHDtXlzpzCVlA82ZieQ8/1+zcxR2eZA=; b=MjL5D6m98+Imx32xyER1nJBpmcFa2tzVN5SDcSy/J/tAg3NUZjb/d5A8S0JAPDxhAG GYIRDynLUtjspz9JE8UeelXmp1g6gvAbgvvct0SGotsLiIB2vCS6b3uRgN7Aotgrw3SK m3MVAnABPGHx4fn5C9HmsigHnOPIS0mawWc0Ey/bLcHbZP551QjVqgAOzuVwfYm4y/uU f+ZitrfhYFFL4zdNo9/0Mu++Da08C0Rzcp6vpMPNo2Ini0iANFXNhaxnvU8vwsKdV0vc zQCZloHiDcdRD1XH28fA3wt8MOhlzjjcKetcaHGDIg85UxnvQyaqlqZso1ikw3QX+D83 PoJA== X-Gm-Message-State: AOAM5336raQWxO5AccdfpkE+/Bu4BfHowBNCdfXGQRBQgidqfoUhHpLX YUHwfVFa9wLUOZAO5CtC/g+83u7eCg9lsreXEvM= X-Google-Smtp-Source: ABdhPJx5uGuLGqre1Sbt/b3UAP2OQicAsLqDswiwv7+VQ/ar3FW66yeMo4RrG7WOJmcaatcdgtpHACsln+Xk7GSevT0= X-Received: by 2002:a05:6e02:689:: with SMTP id o9mr4682771ils.294.1590564714686; Wed, 27 May 2020 00:31:54 -0700 (PDT) MIME-Version: 1.0 References: <20200525212415.3173817-1-thomas@monjalon.net> <20200526160626.GD2554@platinum> <20200527070958.GE2554@platinum> In-Reply-To: <20200527070958.GE2554@platinum> From: Jerin Jacob Date: Wed, 27 May 2020 13:01:38 +0530 Message-ID: To: Olivier Matz Cc: Thomas Monjalon , dpdk-dev , David Marchand , Jerin Jacob , 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 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: > > > > > > 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. 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 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. 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. > > Olivier