All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Wang, Haiyue" <haiyue.wang@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	Olivier Matz <olivier.matz@6wind.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "Andrew Rybchenko" <arybchenko@solarflare.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"Jerin Jacob Kollanukkaran" <jerinj@marvell.com>,
	"Wiles, Keith" <keith.wiles@intel.com>,
	"Morten Brørup" <mb@smartsharesystems.com>,
	"Stephen Hemminger" <stephen@networkplumber.org>,
	"Thomas Monjalon" <thomas@monjalon.net>
Subject: Re: [dpdk-dev] [PATCH v2] mbuf: support dynamic fields and flags
Date: Wed, 23 Oct 2019 03:16:13 +0000	[thread overview]
Message-ID: <E3B9F2FDCB65864C82CD632F23D8AB8773D7E98D@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB97725801A8C6E2BD@IRSMSX104.ger.corp.intel.com>

> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Wednesday, October 23, 2019 06:52
> To: Olivier Matz <olivier.matz@6wind.com>; dev@dpdk.org
> Cc: Andrew Rybchenko <arybchenko@solarflare.com>; Richardson, Bruce <bruce.richardson@intel.com>; Wang,
> Haiyue <haiyue.wang@intel.com>; Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Wiles, Keith
> <keith.wiles@intel.com>; Morten Brørup <mb@smartsharesystems.com>; Stephen Hemminger
> <stephen@networkplumber.org>; Thomas Monjalon <thomas@monjalon.net>
> Subject: RE: [PATCH v2] mbuf: support dynamic fields and flags
> 
> 
> > Many features require to store data inside the mbuf. As the room in mbuf
> > structure is limited, it is not possible to have a field for each
> > feature. Also, changing fields in the mbuf structure can break the API
> > or ABI.
> >
> > This commit addresses these issues, by enabling the dynamic registration
> > of fields or flags:
> >
> > - a dynamic field is a named area in the rte_mbuf structure, with a
> >   given size (>= 1 byte) and alignment constraint.
> > - a dynamic flag is a named bit in the rte_mbuf structure.
> >
> > The typical use case is a PMD that registers space for an offload
> > feature, when the application requests to enable this feature.  As
> > the space in mbuf is limited, the space should only be reserved if it
> > is going to be used (i.e when the application explicitly asks for it).
> >
> > The registration can be done at any moment, but it is not possible
> > to unregister fields or flags for now.
> >
> > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> > Acked-by: Thomas Monjalon <thomas@monjalon.net>
> > ---
> >
> > v2
> >
> > * Rebase on top of master: solve conflict with Stephen's patchset
> >   (packet copy)
> > * Add new apis to register a dynamic field/flag at a specific place
> > * Add a dump function (sugg by David)
> > * Enhance field registration function to select the best offset, keeping
> >   large aligned zones as much as possible (sugg by Konstantin)
> > * Use a size_t and unsigned int instead of int when relevant
> >   (sugg by Konstantin)
> > * Use "uint64_t dynfield1[2]" in mbuf instead of 2 uint64_t fields
> >   (sugg by Konstantin)
> > * Remove unused argument in private function (sugg by Konstantin)
> > * Fix and simplify locking (sugg by Konstantin)
> > * Fix minor typo
> >
> > rfc -> v1
> >
> > * Rebase on top of master
> > * Change registration API to use a structure instead of
> >   variables, getting rid of #defines (Stephen's comment)
> > * Update flag registration to use a similar API as fields.
> > * Change max name length from 32 to 64 (sugg. by Thomas)
> > * Enhance API documentation (Haiyue's and Andrew's comments)
> > * Add a debug log at registration
> > * Add some words in release note
> > * Did some performance tests (sugg. by Andrew):
> >   On my platform, reading a dynamic field takes ~3 cycles more
> >   than a static field, and ~2 cycles more for writing.
> >
> >  app/test/test_mbuf.c                   | 145 ++++++-
> >  doc/guides/rel_notes/release_19_11.rst |   7 +
> >  lib/librte_mbuf/Makefile               |   2 +
> >  lib/librte_mbuf/meson.build            |   6 +-
> >  lib/librte_mbuf/rte_mbuf.h             |  23 +-
> >  lib/librte_mbuf/rte_mbuf_dyn.c         | 548 +++++++++++++++++++++++++
> >  lib/librte_mbuf/rte_mbuf_dyn.h         | 226 ++++++++++
> >  lib/librte_mbuf/rte_mbuf_version.map   |   7 +
> >  8 files changed, 959 insertions(+), 5 deletions(-)
> >  create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.c
> >  create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.h
> >
> > diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
> > index b9c2b2500..01cafad59 100644
> > --- a/app/test/test_mbuf.c
> > +++ b/app/test/test_mbuf.c
> > @@ -28,6 +28,7 @@
> >  #include <rte_random.h>
> >  #include <rte_cycles.h>
> >  #include <rte_malloc.h>
> > +#include <rte_mbuf_dyn.h>
> >

[snip]
> > +int
> > +rte_mbuf_dynflag_register_bitnum(const struct rte_mbuf_dynflag *params,
> > +				unsigned int req)
> > +{
> > +	int ret;
> > +
> > +	if (req != UINT_MAX && req >= 64) {
> 
> Might be better to replace 64 with something like sizeof(mbuf->ol_flags) * CHAR_BIT or so.

Might introduce a new macro like kernel:

/**
 * FIELD_SIZEOF - get the size of a struct's field
 * @t: the target struct
 * @f: the target struct's field
 * Return: the size of @f in the struct definition without having a
 * declared instance of @t.
 */
#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))

Then: FIELD_SIZEOF(rte_mbuf, ol_flags) * CHAR_BIT

> Apart from that:
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> 
> > +		rte_errno = EINVAL;
> > +		return -1;
> > +	}
> > +
> > +	rte_mcfg_tailq_write_lock();
> > +	ret = __rte_mbuf_dynflag_register_bitnum(params, req);
> > +	rte_mcfg_tailq_write_unlock();
> > +
> > +	return ret;
> > +}
> > +

  reply	other threads:[~2019-10-23  3:16 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-10  9:29 [dpdk-dev] [RFC] mbuf: support dynamic fields and flags Olivier Matz
2019-07-10 17:14 ` Wang, Haiyue
2019-07-11  7:26   ` Olivier Matz
2019-07-11  8:04     ` Wang, Haiyue
2019-07-11  8:20       ` Olivier Matz
2019-07-11  8:34         ` Wang, Haiyue
2019-07-11 15:31     ` Stephen Hemminger
2019-07-12  9:18       ` Olivier Matz
2019-07-10 17:49 ` Stephen Hemminger
2019-07-10 18:12   ` Wiles, Keith
2019-07-11  7:53     ` Olivier Matz
2019-07-11 14:37       ` Wiles, Keith
2019-07-12  9:06         ` Olivier Matz
2019-07-11  7:36   ` Olivier Matz
2019-07-12 12:23     ` Jerin Jacob Kollanukkaran
2019-07-16  9:39       ` Olivier Matz
2019-07-16 14:43         ` Stephen Hemminger
2019-07-11  9:24 ` Thomas Monjalon
2019-07-12 14:54 ` Andrew Rybchenko
2019-07-16  9:49   ` Olivier Matz
2019-07-16 11:31     ` [dpdk-dev] ***Spam*** " Andrew Rybchenko
2019-09-18 16:54 ` [dpdk-dev] [PATCH] " Olivier Matz
2019-09-21  4:54   ` Wang, Haiyue
2019-09-23  8:31     ` Olivier Matz
2019-09-23 11:01       ` Wang, Haiyue
2019-09-21  8:28   ` Wiles, Keith
2019-09-23  8:56     ` Morten Brørup
2019-09-23  9:41       ` Olivier Matz
2019-09-23  9:13     ` Olivier Matz
2019-09-23 15:14       ` Wiles, Keith
2019-09-23 16:16         ` Olivier Matz
2019-09-23 17:14           ` Wiles, Keith
2019-09-23 16:09       ` Wiles, Keith
2019-10-01 10:49   ` Ananyev, Konstantin
2019-10-17  7:54     ` Olivier Matz
2019-10-17 11:58       ` Ananyev, Konstantin
2019-10-17 12:58         ` Olivier Matz
2019-10-17 14:42 ` [dpdk-dev] [PATCH v2] " Olivier Matz
2019-10-18  2:47   ` Wang, Haiyue
2019-10-18  7:53     ` Olivier Matz
2019-10-18  8:28       ` Wang, Haiyue
2019-10-18  9:47         ` Olivier Matz
2019-10-18 11:24           ` Wang, Haiyue
2019-10-22 22:51   ` Ananyev, Konstantin
2019-10-23  3:16     ` Wang, Haiyue [this message]
2019-10-23 10:21       ` Olivier Matz
2019-10-23 15:00         ` Stephen Hemminger
2019-10-23 15:12           ` Wang, Haiyue
2019-10-23 10:19     ` Olivier Matz
2019-10-23 11:45       ` Olivier Matz
2019-10-23 11:49         ` Ananyev, Konstantin
2019-10-23 12:00   ` Shahaf Shuler
2019-10-23 13:33     ` Olivier Matz
2019-10-24  4:54       ` Shahaf Shuler
2019-10-24  7:07         ` Olivier Matz
2019-10-24  7:38   ` Slava Ovsiienko
2019-10-24  7:56     ` Olivier Matz
2019-10-24  8:13 ` [dpdk-dev] [PATCH v3] " Olivier Matz
2019-10-24 15:30   ` Stephen Hemminger
2019-10-24 15:44     ` Thomas Monjalon
2019-10-24 17:07       ` Stephen Hemminger
2019-10-24 16:40   ` Thomas Monjalon
2019-10-26 12:39 ` [dpdk-dev] [PATCH v4] " Olivier Matz
2019-10-26 17:04   ` 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=E3B9F2FDCB65864C82CD632F23D8AB8773D7E98D@shsmsx102.ccr.corp.intel.com \
    --to=haiyue.wang@intel.com \
    --cc=arybchenko@solarflare.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.com \
    --cc=keith.wiles@intel.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=mb@smartsharesystems.com \
    --cc=olivier.matz@6wind.com \
    --cc=stephen@networkplumber.org \
    --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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.