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 6AA10A04A4; Tue, 26 May 2020 18:30:03 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7D1EF1D675; Tue, 26 May 2020 18:30:02 +0200 (CEST) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by dpdk.org (Postfix) with ESMTP id DB4181D66C for ; Tue, 26 May 2020 18:30:01 +0200 (CEST) Received: by mail-io1-f67.google.com with SMTP id d7so22713029ioq.5 for ; Tue, 26 May 2020 09:30:01 -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=AYIPg6ApO80OHVlfHcjXVPtskj043VPHPjVc+YnVI1g=; b=B18JwBSxaTbtLToMO8yg9V1CrnR6o+ihLjXlRRR9MP03tgkNYRAl81v00EviR7bQWe qSFiXjTW4NVpQmfrjmkSjMQ6enhslRGBQVSOXpSdgvHPYiyhMarezF6PUDIVyFy8bYYH spN+p5rw+HbYcbnK/fU//9Es4FaoBcyQvkVrmmcqwBAWOimowoYcAzsZfW56MdVTO5GL HRg/i+PyyZJe0O6o5P+mKylNWgI5mfHDOABMGaTllgVweMDeAU6J+kQQs6qQz0gbyVEs 85hy58Z1Z9ykrTbJ6GQKxGfbAxBvyWLcolk5rM7JbHyU0Zb/NMZa33U8h7uT4C0CZIu4 KX+A== 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=AYIPg6ApO80OHVlfHcjXVPtskj043VPHPjVc+YnVI1g=; b=DOQLsVshCv4+DWpqNoVVsPxJLuk52JqYsqVnqP26QEraYE4MHk3PWAbDLdCfS602rb K4j2IANwSUDVgA8lV2QQSro/vji/76fO4AC5fVHufS1wa0MJYpjFDzO23XvVqCacpcJI k8KHJFJlecsXwy2NYsXzA0ikjxRfBXDqGECfmPuiJz8ej+Hq4dBV2whLdMMjojQkJaD2 nzker4WwV5H4wqwQac4/Com5AO9OlFeGbqVaAuOhCL9SOIBUibYWBgw1EcWoJBudOv7L vUGO+Dchobj14BuFkZ5uDAC18Y4VW082lDAkf36jOZDEYCfF5GF152L5lQqovvpKjpp5 yw3g== X-Gm-Message-State: AOAM531z5lWACaFPSPV5YVJk0eHPLsP21SRfO8egitAjBosDvFbHRr2B qGmlqY4FdmgEHBc9qCrcDpEcWWr8ltXPOG7TCXs= X-Google-Smtp-Source: ABdhPJye4OJx++4c+dR+C7ZXrtojIdwopteWM1QJ4R9FCi0205qLBukSoS6KoOve7Qz1MXM/ocBhNncCjPR/4Z19i0s= X-Received: by 2002:a02:4e84:: with SMTP id r126mr1802347jaa.60.1590510600741; Tue, 26 May 2020 09:30:00 -0700 (PDT) MIME-Version: 1.0 References: <20200525212415.3173817-1-thomas@monjalon.net> <20200526160626.GD2554@platinum> In-Reply-To: <20200526160626.GD2554@platinum> From: Jerin Jacob Date: Tue, 26 May 2020 21:59:45 +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 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.