DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerinjacobk@gmail.com>
To: Olivier Matz <olivier.matz@6wind.com>
Cc: Thomas Monjalon <thomas@monjalon.net>, dpdk-dev <dev@dpdk.org>,
	 David Marchand <david.marchand@redhat.com>,
	Jerin Jacob <jerinj@marvell.com>,
	 Nithin Dabilpuram <ndabilpuram@marvell.com>,
	Krzysztof Kanas <kkanas@marvell.com>,
	 Andrew Rybchenko <arybchenko@solarflare.com>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	 "Richardson, Bruce" <bruce.richardson@intel.com>,
	John McNamara <john.mcnamara@intel.com>,
	 Marko Kovacevic <marko.kovacevic@intel.com>
Subject: Re: [dpdk-dev] [PATCH] mbuf: document rule for new fields and flags
Date: Tue, 26 May 2020 21:59:45 +0530
Message-ID: <CALBAE1OaSdEwSoZckCpz1L8cf4g1uLYW9-zLhng-xrX8jdeD1w@mail.gmail.com> (raw)
In-Reply-To: <20200526160626.GD2554@platinum>

On Tue, May 26, 2020 at 9:36 PM Olivier Matz <olivier.matz@6wind.com> 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 <thomas@monjalon.net> 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 <thomas@monjalon.net>
> > > ---
> > >  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.

  reply	other threads:[~2020-05-26 16:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-25 21:24 Thomas Monjalon
2020-05-26  7:39 ` Jerin Jacob
2020-05-26 16:06   ` Olivier Matz
2020-05-26 16:29     ` Jerin Jacob [this message]
2020-05-27  7:09       ` Olivier Matz
2020-05-27  7:31         ` Jerin Jacob
2020-05-27  9:51           ` Thomas Monjalon
2020-05-27 11:43             ` Jerin Jacob
2020-05-27 11:56               ` Thomas Monjalon
2020-05-27 12:07                 ` Jerin Jacob
2020-05-27 12:23                   ` Olivier Matz
2020-05-27 12:34                     ` Jerin Jacob
2020-06-11  6:32 ` [dpdk-dev] [PATCH v2] mbuf: document guideline " Thomas Monjalon
2020-06-11  6:37   ` Jerin Jacob
2020-06-11  7:30     ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALBAE1OaSdEwSoZckCpz1L8cf4g1uLYW9-zLhng-xrX8jdeD1w@mail.gmail.com \
    --to=jerinjacobk@gmail.com \
    --cc=arybchenko@solarflare.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jerinj@marvell.com \
    --cc=john.mcnamara@intel.com \
    --cc=kkanas@marvell.com \
    --cc=marko.kovacevic@intel.com \
    --cc=ndabilpuram@marvell.com \
    --cc=olivier.matz@6wind.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git