mbuf: support dynamic fields and flags
Checks
Commit Message
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>
---
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 | 114 ++++++-
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 | 25 +-
lib/librte_mbuf/rte_mbuf_dyn.c | 408 +++++++++++++++++++++++++
lib/librte_mbuf/rte_mbuf_dyn.h | 163 ++++++++++
lib/librte_mbuf/rte_mbuf_version.map | 4 +
8 files changed, 724 insertions(+), 5 deletions(-)
create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.c
create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.h
Comments
> -----Original Message-----
> From: Olivier Matz [mailto:olivier.matz@6wind.com]
> Sent: Thursday, September 19, 2019 00:55
> To: dev@dpdk.org
> Cc: Thomas Monjalon <thomas@monjalon.net>; Wang, Haiyue <haiyue.wang@intel.com>; Stephen Hemminger
> <stephen@networkplumber.org>; Andrew Rybchenko <arybchenko@solarflare.com>; Wiles, Keith
> <keith.wiles@intel.com>; Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Subject: [PATCH] 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>
> ---
>
> 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 | 114 ++++++-
> 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 | 25 +-
> lib/librte_mbuf/rte_mbuf_dyn.c | 408 +++++++++++++++++++++++++
> lib/librte_mbuf/rte_mbuf_dyn.h | 163 ++++++++++
> lib/librte_mbuf/rte_mbuf_version.map | 4 +
> 8 files changed, 724 insertions(+), 5 deletions(-)
> create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.c
> create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.h
>
[snip]
> +/**
> + * Helper macro to access to a dynamic field.
> + */
> +#define RTE_MBUF_DYNFIELD(m, offset, type) ((type)((uintptr_t)(m) + (offset)))
How about to change it as: ?
#define RTE_MBUF_DYNFIELD(m, offset, type) ((type *)((uintptr_t)(m) + (offset)))
^
Then,
*RTE_MBUF_DYNFIELD(mb, xxx, uint32_t) = yyy;
Since we use 'type' like: sizeof(type), __alignof__(type), this makes 'type' be
more consistent, not have to force cast 'type *' when using it.
const struct rte_mbuf_dynfield dynfield2 = {
.name = "test-dynfield2",
.size = sizeof(uint16_t),
.align = __alignof__(uint16_t),
.flags = 0,
};
And also, when I'm trying to use the dynamic flag, found a macro will be better
for making code align with dynamic field. Just a small suggestion. ;-)
mb->ol_flags |= RTE_MBUF_DYNFLAG(ol_offset);
/**
* Helper macro to access to a dynamic flag.
*/
#define RTE_MBUF_DYNFLAG(offset) (1ULL << (offset))
> +
> +#endif
> diff --git a/lib/librte_mbuf/rte_mbuf_version.map b/lib/librte_mbuf/rte_mbuf_version.map
> index 2662a37bf..a98310570 100644
> --- a/lib/librte_mbuf/rte_mbuf_version.map
> +++ b/lib/librte_mbuf/rte_mbuf_version.map
> @@ -50,4 +50,8 @@ EXPERIMENTAL {
> global:
>
> rte_mbuf_check;
> + rte_mbuf_dynfield_lookup;
> + rte_mbuf_dynfield_register;
> + rte_mbuf_dynflag_lookup;
> + rte_mbuf_dynflag_register;
> } DPDK_18.08;
> --
> 2.20.1
> On Sep 18, 2019, at 6:54 PM, Olivier Matz <olivier.matz@6wind.com> wrote:
>
> 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>
> —
>
The idea of registration for space in the mbuf I am not a big fan. I did like Konstantin’s suggestion of having the compiler help with optimizing the code, but with a slight difference. Maybe I misunderstand, but now with this design you have to pass the offsets to different parts of the application or place in global memory or have each section request the offsets. It seems great if the application is one big application or an appliance model application having control of the whole design not so good for service chains like designs where different parts of the whole application is design by different teams.
Konstantin’s suggest if I understand it was to use structures to allow the compiler to optimize the access to the mbuf and I like that idea, but with one change we add a field in the mbuf to define the mbuf structure type.
Say 0 is the standard rte_mbuf type then type 1 could be the IPSec offset type mbuf, type 2 could be something else, … The type 0 looks just like the mbuf we have today with maybe the optional fields set to reserved or some type of filler variables to reserve the holes in the structure. Then type 1 is the IPSec mbuf and in the reserved sections of the mbuf contain the IPSec related data with the standard mbuf fields still matching the type 0 version.
This allows the mbuf to be used by the developer and the compiler now knows exactly where the fields are located in the structure and does not have to deal with any of the macros and offsets and registration suggested here. Just cast the mbuf pointer into the new type mbuf structure. We just have to make sure the code that needs to use a given mbuf type has access to the structure definitions.
If the mbufs it going to be translated from one type mbuf to another mbuf type, we just have to define that type and then cast the mbuf pointer to that structure. When an mbuf is received from IPSec PMD then the application needs to forward that mbuf to the next stage it can reset the type to 0 or to another type filling in the reserved fields to be used by the next stage in the pipeline.
The mbuf now contains the type and every point in the application can look at the type to determine how that mbuf is defined. I am sure there are some holes here, but I think it is a better solution then using all of these macros, offset values and registration APIs.
Regards,
Keith
Hi,
On Sat, Sep 21, 2019 at 04:54:39AM +0000, Wang, Haiyue wrote:
> > -----Original Message-----
> > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > Sent: Thursday, September 19, 2019 00:55
> > To: dev@dpdk.org
> > Cc: Thomas Monjalon <thomas@monjalon.net>; Wang, Haiyue <haiyue.wang@intel.com>; Stephen Hemminger
> > <stephen@networkplumber.org>; Andrew Rybchenko <arybchenko@solarflare.com>; Wiles, Keith
> > <keith.wiles@intel.com>; Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> > Subject: [PATCH] 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>
> > ---
> >
> > 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 | 114 ++++++-
> > 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 | 25 +-
> > lib/librte_mbuf/rte_mbuf_dyn.c | 408 +++++++++++++++++++++++++
> > lib/librte_mbuf/rte_mbuf_dyn.h | 163 ++++++++++
> > lib/librte_mbuf/rte_mbuf_version.map | 4 +
> > 8 files changed, 724 insertions(+), 5 deletions(-)
> > create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.c
> > create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.h
> >
>
> [snip]
>
> > +/**
> > + * Helper macro to access to a dynamic field.
> > + */
> > +#define RTE_MBUF_DYNFIELD(m, offset, type) ((type)((uintptr_t)(m) + (offset)))
>
> How about to change it as: ?
> #define RTE_MBUF_DYNFIELD(m, offset, type) ((type *)((uintptr_t)(m) + (offset)))
> ^
> Then,
> *RTE_MBUF_DYNFIELD(mb, xxx, uint32_t) = yyy;
>
> Since we use 'type' like: sizeof(type), __alignof__(type), this makes 'type' be
> more consistent, not have to force cast 'type *' when using it.
>
> const struct rte_mbuf_dynfield dynfield2 = {
> .name = "test-dynfield2",
> .size = sizeof(uint16_t),
> .align = __alignof__(uint16_t),
> .flags = 0,
> };
Yes, I don't see use cases where the '*' is omitted, so it could be in the
macro. On the other hand, doing like in the patch is more consistent with
similar macros like rte_pktmbuf_mtod(), so I'll tend to keep it as is.
This is maybe not that important, because this macro will often be hidden
in a wrapper, like below:
static inline uint64_t rte_mbuf_dyn_timestamp_get(const struct rte_mbuf *m)
{
return *RTE_MBUF_DYNFIELD(m, rte_mbuf_dynfield_timestamp_offset,
uint64_t *);
}
> And also, when I'm trying to use the dynamic flag, found a macro will be better
> for making code align with dynamic field. Just a small suggestion. ;-)
> mb->ol_flags |= RTE_MBUF_DYNFLAG(ol_offset);
>
> /**
> * Helper macro to access to a dynamic flag.
> */
> #define RTE_MBUF_DYNFLAG(offset) (1ULL << (offset))
OK, I will add it in next version.
Thank you for the feedback!
Olivier
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wiles, Keith
> Sent: Saturday, September 21, 2019 10:29 AM
>
> > On Sep 18, 2019, at 6:54 PM, Olivier Matz <olivier.matz@6wind.com>
> wrote:
> >
> > 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>
> > —
> >
>
> The idea of registration for space in the mbuf I am not a big fan. I
> did like Konstantin’s suggestion of having the compiler help with
> optimizing the code, but with a slight difference. Maybe I
> misunderstand, but now with this design you have to pass the offsets to
> different parts of the application or place in global memory or have
> each section request the offsets. It seems great if the application is
> one big application or an appliance model application having control of
> the whole design not so good for service chains like designs where
> different parts of the whole application is design by different teams.
>
> Konstantin’s suggest if I understand it was to use structures to allow
> the compiler to optimize the access to the mbuf and I like that idea,
> but with one change we add a field in the mbuf to define the mbuf
> structure type.
>
> Say 0 is the standard rte_mbuf type then type 1 could be the IPSec
> offset type mbuf, type 2 could be something else, … The type 0 looks
> just like the mbuf we have today with maybe the optional fields set to
> reserved or some type of filler variables to reserve the holes in the
> structure. Then type 1 is the IPSec mbuf and in the reserved sections
> of the mbuf contain the IPSec related data with the standard mbuf
> fields still matching the type 0 version.
>
> This allows the mbuf to be used by the developer and the compiler now
> knows exactly where the fields are located in the structure and does
> not have to deal with any of the macros and offsets and registration
> suggested here. Just cast the mbuf pointer into the new type mbuf
> structure. We just have to make sure the code that needs to use a given
> mbuf type has access to the structure definitions.
>
> If the mbufs it going to be translated from one type mbuf to another
> mbuf type, we just have to define that type and then cast the mbuf
> pointer to that structure. When an mbuf is received from IPSec PMD then
> the application needs to forward that mbuf to the next stage it can
> reset the type to 0 or to another type filling in the reserved fields
> to be used by the next stage in the pipeline.
>
> The mbuf now contains the type and every point in the application can
> look at the type to determine how that mbuf is defined. I am sure there
> are some holes here, but I think it is a better solution then using all
> of these macros, offset values and registration APIs.
>
>
> Regards,
> Keith
First of all, I applaud the idea of cleaning up the mbuf structure and removing the fields only rarely used and/or for special use cases only, as mentioned in the presentation, e.g. timestamp, timesync and seqn. It is great seeing serious effort put into improving the very core of DPDK!
However, after some hallway discussions at DPDK Userspace and further thinking about the details, I can see two additional risks by introducing dynamic mbufs, which I would like to share for your consideration:
1. It may prevent us from adding future solutions not yet considered.
If we were to introduce new functions for more granular handling of mbufs, similar to some of the Linux kernel's skbuff handling functions, how should such functions handle the dynamic fields? And how is the rte_pktmbuf_clone() function supposed to handle the dynamic fields? Some fields may need to be copied as-is, some may need to be initialized to zero or some other value, and so on. It is apparently not a problem now; but dynamic mbufs may prevent us from adding some of such functions in the future.
I admit that I can only imagine the issue on an abstract level, so I can't give you a concrete example. Perhaps some of the more experienced Linux developers can provide one or debunk my concern. (Stephen: In relation to packet capturing we were discussing the reference counter not being respected by some applications, and the possible need for more granular mbuf handling.)
2. In the long run, we might end up adding more fields than we remove.
Dynamic mbufs makes it easier to add specialized fields, which is great. But when the barrier to adding specialized fields is reduced, more PMDs and libraries may add their own unique fields, rather than going through a discussion and consensus for adding them to the fixed mbuf structure or finding some other solution. And if a multitude of PMDs each need a specialized field, PMDs might end up adding variants of a field, rather than reaching consensus for a common standard. It will be much easier to just add your own specialized mbuf field rather than having to go through the standardization process in the DPDK community.
I will use the timestamp field as a theoretic example: The packet timestamp measurement unit differs between vendors, so with dynamic mbufs one vendor's PMD might create a timestamp_ns field, counting in nanoseconds, and another vendor's PMD might create a timestamp_clocks field, counting in clock counts. With the fixed mbuf, this triggered a public discussion, and a compromise for the field was reached.
Although I am worried about dynamic mbufs, I don't have a better suggestion. And perhaps I just worry too much.
Med venlig hilsen / kind regards
- Morten Brørup
Hi Keith,
On Sat, Sep 21, 2019 at 08:28:32AM +0000, Wiles, Keith wrote:
>
>
> > On Sep 18, 2019, at 6:54 PM, Olivier Matz <olivier.matz@6wind.com> wrote:
> >
> > 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>
> > —
> >
>
> The idea of registration for space in the mbuf I am not a big fan. I did like
> Konstantin’s suggestion of having the compiler help with optimizing the code,
> but with a slight difference. Maybe I misunderstand, but now with this design
> you have to pass the offsets to different parts of the application or place in
> global memory or have each section request the offsets. It seems great if the
> application is one big application or an appliance model application having
> control of the whole design not so good for service chains like designs where
> different parts of the whole application is design by different teams.
If the global variable storing the offset is defined in the mbuf layer, what
would be the problem?
The only things you would have to do is:
1/ ensure the offset is registered
rte_mbuf_dyn_timestamp_register()
2/ use helpers
rte_mbuf_dyn_timestamp_get(), rte_mbuf_dyn_timestamp_set(), ...
> Konstantin’s suggest if I understand it was to use structures to allow the
> compiler to optimize the access to the mbuf and I like that idea, but with one
> change we add a field in the mbuf to define the mbuf structure type.
>
> Say 0 is the standard rte_mbuf type then type 1 could be the IPSec offset type
> mbuf, type 2 could be something else, … The type 0 looks just like the mbuf we
> have today with maybe the optional fields set to reserved or some type of
> filler variables to reserve the holes in the structure. Then type 1 is the
> IPSec mbuf and in the reserved sections of the mbuf contain the IPSec related
> data with the standard mbuf fields still matching the type 0 version.
This very look like the "selective layout" in our presentation [1], page 14.
Your example talks about IPsec, but someone else will want to use a
sequence number, another one a timestamp, and another one will want to
use this space for its own application. There are a lot of use cases,
and it does not scale to have a layout for each of them. Worst, if
someone wants IPsec + a sequence number, how can it work?
One of the problem to solve is to avoid mutually exclusive feature (i.e.
union of fields that cannot be used together in the mbuf).
> This allows the mbuf to be used by the developer and the compiler now knows
> exactly where the fields are located in the structure and does not have to
> deal with any of the macros and offsets and registration suggested here. Just
> cast the mbuf pointer into the new type mbuf structure. We just have to make
> sure the code that needs to use a given mbuf type has access to the structure
> definitions.
With the current proposal, we can imagine an API to ask to register a
field at a specific offset. It can then be used in the application, so
that accesses are done at no cost compared to a static field, because
the offset would be const.
In the driver, the same logic could be used, but dynamically:
if (offset == PREFERRED_OFFSET) {
/* code with static offset */
} else {
/* generic code */
}
But I'm not sure it would scale a lot if there are several features
using dynamic fields.
> If the mbufs it going to be translated from one type mbuf to another mbuf
> type, we just have to define that type and then cast the mbuf pointer to that
> structure. When an mbuf is received from IPSec PMD then the application needs
> to forward that mbuf to the next stage it can reset the type to 0 or to
> another type filling in the reserved fields to be used by the next stage in
> the pipeline.
What you describe is one use case.
What could be done with the API mentionned above (but I think it is
dangerous), is to allow a user to register 2 different fields at the
same offset, using a specific flag. This could work if the user knows
that these 2 fields are never used at the same time.
> The mbuf now contains the type and every point in the application can look at
> the type to determine how that mbuf is defined. I am sure there are some holes
> here, but I think it is a better solution then using all of these macros,
> offset values and registration APIs.
I'm not convinced having selective layouts is doable. The layouts cannot
fit all possible use cases, and managing the different layouts in the
driver looks difficult to me. Additionnaly, it does not solve the
problem of mutually exclusive features.
Thanks for the feedback.
Olivier
[1] https://static.sched.com/hosted_files/dpdkbordeaux2019/2b/dpdk-201909-dyn-mbuf.pdf
Hi Morten,
On Mon, Sep 23, 2019 at 10:56:01AM +0200, Morten Brørup wrote:
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wiles, Keith
> > Sent: Saturday, September 21, 2019 10:29 AM
> >
> > > On Sep 18, 2019, at 6:54 PM, Olivier Matz <olivier.matz@6wind.com>
> > wrote:
> > >
> > > 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>
> > > —
> > >
> >
> > The idea of registration for space in the mbuf I am not a big fan. I
> > did like Konstantin’s suggestion of having the compiler help with
> > optimizing the code, but with a slight difference. Maybe I
> > misunderstand, but now with this design you have to pass the offsets to
> > different parts of the application or place in global memory or have
> > each section request the offsets. It seems great if the application is
> > one big application or an appliance model application having control of
> > the whole design not so good for service chains like designs where
> > different parts of the whole application is design by different teams.
> >
> > Konstantin’s suggest if I understand it was to use structures to allow
> > the compiler to optimize the access to the mbuf and I like that idea,
> > but with one change we add a field in the mbuf to define the mbuf
> > structure type.
> >
> > Say 0 is the standard rte_mbuf type then type 1 could be the IPSec
> > offset type mbuf, type 2 could be something else, … The type 0 looks
> > just like the mbuf we have today with maybe the optional fields set to
> > reserved or some type of filler variables to reserve the holes in the
> > structure. Then type 1 is the IPSec mbuf and in the reserved sections
> > of the mbuf contain the IPSec related data with the standard mbuf
> > fields still matching the type 0 version.
> >
> > This allows the mbuf to be used by the developer and the compiler now
> > knows exactly where the fields are located in the structure and does
> > not have to deal with any of the macros and offsets and registration
> > suggested here. Just cast the mbuf pointer into the new type mbuf
> > structure. We just have to make sure the code that needs to use a given
> > mbuf type has access to the structure definitions.
> >
> > If the mbufs it going to be translated from one type mbuf to another
> > mbuf type, we just have to define that type and then cast the mbuf
> > pointer to that structure. When an mbuf is received from IPSec PMD then
> > the application needs to forward that mbuf to the next stage it can
> > reset the type to 0 or to another type filling in the reserved fields
> > to be used by the next stage in the pipeline.
> >
> > The mbuf now contains the type and every point in the application can
> > look at the type to determine how that mbuf is defined. I am sure there
> > are some holes here, but I think it is a better solution then using all
> > of these macros, offset values and registration APIs.
> >
> >
> > Regards,
> > Keith
>
>
> First of all, I applaud the idea of cleaning up the mbuf structure and
> removing the fields only rarely used and/or for special use cases only, as
> mentioned in the presentation, e.g. timestamp, timesync and seqn. It is great
> seeing serious effort put into improving the very core of DPDK!
>
> However, after some hallway discussions at DPDK Userspace and further thinking
> about the details, I can see two additional risks by introducing dynamic
> mbufs, which I would like to share for your consideration:
>
> 1. It may prevent us from adding future solutions not yet considered.
>
> If we were to introduce new functions for more granular handling of mbufs,
> similar to some of the Linux kernel's skbuff handling functions, how should
> such functions handle the dynamic fields? And how is the rte_pktmbuf_clone()
> function supposed to handle the dynamic fields? Some fields may need to be
> copied as-is, some may need to be initialized to zero or some other value, and
> so on. It is apparently not a problem now; but dynamic mbufs may prevent us
> from adding some of such functions in the future.
>
> I admit that I can only imagine the issue on an abstract level, so I can't
> give you a concrete example. Perhaps some of the more experienced Linux
> developers can provide one or debunk my concern. (Stephen: In relation to
> packet capturing we were discussing the reference counter not being respected
> by some applications, and the possible need for more granular mbuf handling.)
For now, the clone copies the fields. If we introduce a copy function, I
think it should do the same. Right now, I cannot find a use case where
the field should be set to another value, but yes, this could be a
limitation.
> 2. In the long run, we might end up adding more fields than we remove.
>
> Dynamic mbufs makes it easier to add specialized fields, which is great. But
> when the barrier to adding specialized fields is reduced, more PMDs and
> libraries may add their own unique fields, rather than going through a
> discussion and consensus for adding them to the fixed mbuf structure or
> finding some other solution. And if a multitude of PMDs each need a
> specialized field, PMDs might end up adding variants of a field, rather than
> reaching consensus for a common standard. It will be much easier to just add
> your own specialized mbuf field rather than having to go through the
> standardization process in the DPDK community.
>
> I will use the timestamp field as a theoretic example: The packet timestamp
> measurement unit differs between vendors, so with dynamic mbufs one vendor's
> PMD might create a timestamp_ns field, counting in nanoseconds, and another
> vendor's PMD might create a timestamp_clocks field, counting in clock
> counts. With the fixed mbuf, this triggered a public discussion, and a
> compromise for the field was reached.
In the mbuf structure, there is not a lot of room to describe some of
the fields, especially the ones that are inside a structure of union of
structure of union of union ;)
The definition of a dynamic field is in a dedicated structure, so there
is more room to describe it. For public dynamic fields, we have to be as
strict as for static fields, because it will be a public API. It has to
be correctly defined. About your timestamp example, we should not allow
2 different timestamp formats in the public API.
For private fields (Lib only, App only, PMD only), it's less critical
because it is not public, even if it's always good to have a clear
description.
> Although I am worried about dynamic mbufs, I don't have a better
> suggestion. And perhaps I just worry too much.
Feedback is always good to have, thanks.
Olivier
> -----Original Message-----
> From: Olivier Matz [mailto:olivier.matz@6wind.com]
> Sent: Monday, September 23, 2019 16:32
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: dev@dpdk.org; Thomas Monjalon <thomas@monjalon.net>; Stephen Hemminger
> <stephen@networkplumber.org>; Andrew Rybchenko <arybchenko@solarflare.com>; Wiles, Keith
> <keith.wiles@intel.com>; Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Subject: Re: [PATCH] mbuf: support dynamic fields and flags
>
> Hi,
>
> On Sat, Sep 21, 2019 at 04:54:39AM +0000, Wang, Haiyue wrote:
> > > -----Original Message-----
> > > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > > Sent: Thursday, September 19, 2019 00:55
> > > To: dev@dpdk.org
> > > Cc: Thomas Monjalon <thomas@monjalon.net>; Wang, Haiyue <haiyue.wang@intel.com>; Stephen Hemminger
> > > <stephen@networkplumber.org>; Andrew Rybchenko <arybchenko@solarflare.com>; Wiles, Keith
> > > <keith.wiles@intel.com>; Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> > > Subject: [PATCH] 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>
> > > ---
> > >
> > > 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 | 114 ++++++-
> > > 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 | 25 +-
> > > lib/librte_mbuf/rte_mbuf_dyn.c | 408 +++++++++++++++++++++++++
> > > lib/librte_mbuf/rte_mbuf_dyn.h | 163 ++++++++++
> > > lib/librte_mbuf/rte_mbuf_version.map | 4 +
> > > 8 files changed, 724 insertions(+), 5 deletions(-)
> > > create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.c
> > > create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.h
> > >
> >
> > [snip]
> >
> > > +/**
> > > + * Helper macro to access to a dynamic field.
> > > + */
> > > +#define RTE_MBUF_DYNFIELD(m, offset, type) ((type)((uintptr_t)(m) + (offset)))
> >
> > How about to change it as: ?
> > #define RTE_MBUF_DYNFIELD(m, offset, type) ((type *)((uintptr_t)(m) + (offset)))
> > ^
> > Then,
> > *RTE_MBUF_DYNFIELD(mb, xxx, uint32_t) = yyy;
> >
> > Since we use 'type' like: sizeof(type), __alignof__(type), this makes 'type' be
> > more consistent, not have to force cast 'type *' when using it.
> >
> > const struct rte_mbuf_dynfield dynfield2 = {
> > .name = "test-dynfield2",
> > .size = sizeof(uint16_t),
> > .align = __alignof__(uint16_t),
> > .flags = 0,
> > };
>
> Yes, I don't see use cases where the '*' is omitted, so it could be in the
> macro. On the other hand, doing like in the patch is more consistent with
> similar macros like rte_pktmbuf_mtod(), so I'll tend to keep it as is.
>
> This is maybe not that important, because this macro will often be hidden
> in a wrapper, like below:
>
> static inline uint64_t rte_mbuf_dyn_timestamp_get(const struct rte_mbuf *m)
> {
> return *RTE_MBUF_DYNFIELD(m, rte_mbuf_dynfield_timestamp_offset,
> uint64_t *);
> }
>
Thanks, yes, the same style as 'rte_pktmbuf_mtod', I didn't notice it.
>
> Thank you for the feedback!
>
> Olivier
On Sep 23, 2019, at 4:13 AM, Olivier Matz <olivier.matz@6wind.com<mailto:olivier.matz@6wind.com>> wrote:
Hi Keith,
On Sat, Sep 21, 2019 at 08:28:32AM +0000, Wiles, Keith wrote:
On Sep 18, 2019, at 6:54 PM, Olivier Matz <olivier.matz@6wind.com<mailto:olivier.matz@6wind.com>> wrote:
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<mailto:olivier.matz@6wind.com>>
Acked-by: Thomas Monjalon <thomas@monjalon.net<mailto:thomas@monjalon.net>>
—
The idea of registration for space in the mbuf I am not a big fan. I did like
Konstantin’s suggestion of having the compiler help with optimizing the code,
but with a slight difference. Maybe I misunderstand, but now with this design
you have to pass the offsets to different parts of the application or place in
global memory or have each section request the offsets. It seems great if the
application is one big application or an appliance model application having
control of the whole design not so good for service chains like designs where
different parts of the whole application is design by different teams.
If the global variable storing the offset is defined in the mbuf layer, what
would be the problem?
Are you assuming the values are shared between primary/secondary model or between processes using shared memory? If moving the packet data via shared memory to a different application written by a different company you still have to move that metadata. If the type was carried with the mbuf we can easily convey a small type value or we would need to tell the other side we have all of this registration information to send. I would suggest the number of mbuf types will be small over time and I believe a 4 bit or 8 bit type is reasonable. In many protocols using a type value is used to convey this type of information. We can even tightly control the number of types DPDK controls and then leave some for user defined if we like.
The only things you would have to do is:
1/ ensure the offset is registered
rte_mbuf_dyn_timestamp_register()
2/ use helpers
rte_mbuf_dyn_timestamp_get(), rte_mbuf_dyn_timestamp_set(), ...
Konstantin’s suggest if I understand it was to use structures to allow the
compiler to optimize the access to the mbuf and I like that idea, but with one
change we add a field in the mbuf to define the mbuf structure type.
Say 0 is the standard rte_mbuf type then type 1 could be the IPSec offset type
mbuf, type 2 could be something else, … The type 0 looks just like the mbuf we
have today with maybe the optional fields set to reserved or some type of
filler variables to reserve the holes in the structure. Then type 1 is the
IPSec mbuf and in the reserved sections of the mbuf contain the IPSec related
data with the standard mbuf fields still matching the type 0 version.
This very look like the "selective layout" in our presentation [1], page 14.
Your example talks about IPsec, but someone else will want to use a
sequence number, another one a timestamp, and another one will want to
use this space for its own application. There are a lot of use cases,
and it does not scale to have a layout for each of them. Worst, if
someone wants IPsec + a sequence number, how can it work?
One of the problem to solve is to avoid mutually exclusive feature (i.e.
union of fields that cannot be used together in the mbuf).
This allows the mbuf to be used by the developer and the compiler now knows
exactly where the fields are located in the structure and does not have to
deal with any of the macros and offsets and registration suggested here. Just
cast the mbuf pointer into the new type mbuf structure. We just have to make
sure the code that needs to use a given mbuf type has access to the structure
definitions.
With the current proposal, we can imagine an API to ask to register a
field at a specific offset. It can then be used in the application, so
that accesses are done at no cost compared to a static field, because
the offset would be const.
In the driver, the same logic could be used, but dynamically:
if (offset == PREFERRED_OFFSET) {
/* code with static offset */
} else {
/* generic code */
}
But I'm not sure it would scale a lot if there are several features
using dynamic fields.
If the mbufs it going to be translated from one type mbuf to another mbuf
type, we just have to define that type and then cast the mbuf pointer to that
structure. When an mbuf is received from IPSec PMD then the application needs
to forward that mbuf to the next stage it can reset the type to 0 or to
another type filling in the reserved fields to be used by the next stage in
the pipeline.
What you describe is one use case.
What could be done with the API mentionned above (but I think it is
dangerous), is to allow a user to register 2 different fields at the
same offset, using a specific flag. This could work if the user knows
that these 2 fields are never used at the same time.
The mbuf now contains the type and every point in the application can look at
the type to determine how that mbuf is defined. I am sure there are some holes
here, but I think it is a better solution then using all of these macros,
offset values and registration APIs.
I'm not convinced having selective layouts is doable. The layouts cannot
fit all possible use cases, and managing the different layouts in the
driver looks difficult to me. Additionnaly, it does not solve the
problem of mutually exclusive features.
I too at one time wanted some type of allocation or registration for private mbuf space and applying to these limited fields in the mbuf header may have been reasonable. The problem is using registration and moving that information between processes is going to be hard to get right. For a single Appliance model application it would work great and not in a non-appliance model applications. The type/structure method can help and it could have problems too, but using a type/struct design seems to be one of the BKMs (Best Known Methods) in the industry.
To be honest it maybe we just take the hit in performance and add a third cache line as I am sure trying to squeeze metadata into these very limit fields will be a challenge IMO. I am not suggesting we add a cache line to every mbuf only to the pools that require the extra metadata by using the private space if that is reasonable. The applications needing a lot of metadata will just have to take the hit in performance anyway.
Having to grab a metadata value via a set of macros and inline functions seems like it will consume more cycles then just a type/structure method as the compiler will help optimize the code without having to call any macros or inline functions.
Thanks for the feedback.
Olivier
[1] https://static.sched.com/hosted_files/dpdkbordeaux2019/2b/dpdk-201909-dyn-mbuf.pdf
Regards,
Keith
Sorry, resend in plain text :-(
> On Sep 23, 2019, at 4:13 AM, Olivier Matz <olivier.matz@6wind.com> wrote:
>
> Hi Keith,
>
> On Sat, Sep 21, 2019 at 08:28:32AM +0000, Wiles, Keith wrote:
>>
>>
>>> On Sep 18, 2019, at 6:54 PM, Olivier Matz <olivier.matz@6wind.com> wrote:
>>>
>>> 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>
>>> —
>>>
>>
>
>> The idea of registration for space in the mbuf I am not a big fan. I did like
>> Konstantin’s suggestion of having the compiler help with optimizing the code,
>> but with a slight difference. Maybe I misunderstand, but now with this design
>> you have to pass the offsets to different parts of the application or place in
>> global memory or have each section request the offsets. It seems great if the
>> application is one big application or an appliance model application having
>> control of the whole design not so good for service chains like designs where
>> different parts of the whole application is design by different teams.
>
> If the global variable storing the offset is defined in the mbuf layer, what
> would be the problem?
>
Are you assuming the values are shared between primary/secondary model or between processes using shared memory? If moving the packet data via shared memory to a different application written by a different company you still have to move that metadata. If the type was carried with the mbuf we can easily convey a small type value or we would need to tell the other side we have all of this registration information to send. I would suggest the number of mbuf types will be small over time and I believe a 4 bit or 8 bit type is reasonable. In many protocols using a type value is used to convey this type of information. We can even tightly control the number of types DPDK controls and then leave some for user defined if we like.
> The only things you would have to do is:
>
> 1/ ensure the offset is registered
> rte_mbuf_dyn_timestamp_register()
>
> 2/ use helpers
> rte_mbuf_dyn_timestamp_get(), rte_mbuf_dyn_timestamp_set(), ...
>
>> Konstantin’s suggest if I understand it was to use structures to allow the
>> compiler to optimize the access to the mbuf and I like that idea, but with one
>> change we add a field in the mbuf to define the mbuf structure type.
>>
>> Say 0 is the standard rte_mbuf type then type 1 could be the IPSec offset type
>> mbuf, type 2 could be something else, … The type 0 looks just like the mbuf we
>> have today with maybe the optional fields set to reserved or some type of
>> filler variables to reserve the holes in the structure. Then type 1 is the
>> IPSec mbuf and in the reserved sections of the mbuf contain the IPSec related
>> data with the standard mbuf fields still matching the type 0 version.
>
> This very look like the "selective layout" in our presentation [1], page 14.
>
> Your example talks about IPsec, but someone else will want to use a
> sequence number, another one a timestamp, and another one will want to
> use this space for its own application. There are a lot of use cases,
> and it does not scale to have a layout for each of them. Worst, if
> someone wants IPsec + a sequence number, how can it work?
>
> One of the problem to solve is to avoid mutually exclusive feature (i.e.
> union of fields that cannot be used together in the mbuf).
>
>> This allows the mbuf to be used by the developer and the compiler now knows
>> exactly where the fields are located in the structure and does not have to
>> deal with any of the macros and offsets and registration suggested here. Just
>> cast the mbuf pointer into the new type mbuf structure. We just have to make
>> sure the code that needs to use a given mbuf type has access to the structure
>> definitions.
>
> With the current proposal, we can imagine an API to ask to register a
> field at a specific offset. It can then be used in the application, so
> that accesses are done at no cost compared to a static field, because
> the offset would be const.
>
> In the driver, the same logic could be used, but dynamically:
>
> if (offset == PREFERRED_OFFSET) {
> /* code with static offset */
> } else {
> /* generic code */
> }
>
> But I'm not sure it would scale a lot if there are several features
> using dynamic fields.
>
>> If the mbufs it going to be translated from one type mbuf to another mbuf
>> type, we just have to define that type and then cast the mbuf pointer to that
>> structure. When an mbuf is received from IPSec PMD then the application needs
>> to forward that mbuf to the next stage it can reset the type to 0 or to
>> another type filling in the reserved fields to be used by the next stage in
>> the pipeline.
>
> What you describe is one use case.
>
> What could be done with the API mentionned above (but I think it is
> dangerous), is to allow a user to register 2 different fields at the
> same offset, using a specific flag. This could work if the user knows
> that these 2 fields are never used at the same time.
>
>> The mbuf now contains the type and every point in the application can look at
>> the type to determine how that mbuf is defined. I am sure there are some holes
>> here, but I think it is a better solution then using all of these macros,
>> offset values and registration APIs.
>
> I'm not convinced having selective layouts is doable. The layouts cannot
> fit all possible use cases, and managing the different layouts in the
> driver looks difficult to me. Additionnaly, it does not solve the
> problem of mutually exclusive features.
>
I too at one time wanted some type of allocation or registration for private mbuf space and applying to these limited fields in the mbuf header may have been reasonable. The problem is using registration and moving that information between processes is going to be hard to get right. For a single Appliance model application it would work great and not in a non-appliance model applications. The type/structure method can help and it could have problems too, but using a type/struct design seems to be one of the BKMs (Best Known Methods) in the industry.
To be honest it maybe we just take the hit in performance and add a third cache line as I am sure trying to squeeze metadata into these very limit fields will be a challenge IMO. I am not suggesting we add a cache line to every mbuf only to the pools that require the extra metadata by using the private space if that is reasonable. The applications needing a lot of metadata will just have to take the hit in performance anyway.
Having to grab a metadata value via a set of macros and inline functions seems like it will consume more cycles then just a type/structure method as the compiler will help optimize the code without having to call any macros or inline functions.
>
> Thanks for the feedback.
> Olivier
>
> [1] https://static.sched.com/hosted_files/dpdkbordeaux2019/2b/dpdk-201909-dyn-mbuf.pdf
Regards,
Keith
Hi,
(reformated the quotes)
On Mon, Sep 23, 2019 at 03:14:51PM +0000, Wiles, Keith wrote:
>
>
> On Sep 23, 2019, at 4:13 AM, Olivier Matz <olivier.matz@6wind.com<mailto:olivier.matz@6wind.com>> wrote:
> >
> > Hi Keith,
> >
> > On Sat, Sep 21, 2019 at 08:28:32AM +0000, Wiles, Keith wrote:
> > >
> > >
> > > On Sep 18, 2019, at 6:54 PM, Olivier Matz <olivier.matz@6wind.com<mailto:olivier.matz@6wind.com>> wrote:
> > >
> > > > 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<mailto:olivier.matz@6wind.com>>
> > > > Acked-by: Thomas Monjalon <thomas@monjalon.net<mailto:thomas@monjalon.net>>
> > > —
> > >
> > >
> > >
> > > The idea of registration for space in the mbuf I am not a big fan. I did like
> > > Konstantin’s suggestion of having the compiler help with optimizing the code,
> > > but with a slight difference. Maybe I misunderstand, but now with this design
> > > you have to pass the offsets to different parts of the application or place in
> > > global memory or have each section request the offsets. It seems great if the
> > > application is one big application or an appliance model application having
> > > control of the whole design not so good for service chains like designs where
> > > different parts of the whole application is design by different teams.
> >
> > If the global variable storing the offset is defined in the mbuf layer, what
> > would be the problem?
>
> Are you assuming the values are shared between primary/secondary model or
> between processes using shared memory? If moving the packet data via shared
> memory to a different application written by a different company you still
> have to move that metadata.
The dynamic mbuf proposal works with secondary processes. What does that
change if the application is written by a different company? If you need
to store a timestamp, you register the timestamp and the offset will be
the same in primary and secondary.
> If the type was carried with the mbuf we can easily convey a small
> type value or we would need to tell the other side we have all of this
> registration information to send. I would suggest the number of mbuf
> types will be small over time and I believe a 4 bit or 8 bit type is
> reasonable. In many protocols using a type value is used to convey
> this type of information. We can even tightly control the number of
> types DPDK controls and then leave some for user defined if we like.
8 bits means 256 different mbuf layouts.
You did not replied to my previous questions:
- what happens if you need a field from layout1 and another from layout2?
(ex: timestamp + ipsec, timestamp + seqn, seqn + ipsec, ...)
- how do you implement the rx/tx drivers functions if you have to support
several layouts, where a field may be at a different offset?
> > > The only things you would have to do is:
> > >
> > > 1/ ensure the offset is registered
> > > rte_mbuf_dyn_timestamp_register()
> > >
> > > 2/ use helpers
> > > rte_mbuf_dyn_timestamp_get(), rte_mbuf_dyn_timestamp_set(), ...
>
> > Konstantin’s suggest if I understand it was to use structures to allow the
> > compiler to optimize the access to the mbuf and I like that idea, but with one
> > change we add a field in the mbuf to define the mbuf structure type.
> >
> > Say 0 is the standard rte_mbuf type then type 1 could be the IPSec offset type
> > mbuf, type 2 could be something else, … The type 0 looks just like the mbuf we
> > have today with maybe the optional fields set to reserved or some type of
> > filler variables to reserve the holes in the structure. Then type 1 is the
> > IPSec mbuf and in the reserved sections of the mbuf contain the IPSec related
> > data with the standard mbuf fields still matching the type 0 version.
>
> This very look like the "selective layout" in our presentation [1], page 14.
>
> Your example talks about IPsec, but someone else will want to use a
> sequence number, another one a timestamp, and another one will want to
> use this space for its own application. There are a lot of use cases,
> and it does not scale to have a layout for each of them. Worst, if
> someone wants IPsec + a sequence number, how can it work?
>
> One of the problem to solve is to avoid mutually exclusive feature (i.e.
> union of fields that cannot be used together in the mbuf).
>
> This allows the mbuf to be used by the developer and the compiler now knows
> exactly where the fields are located in the structure and does not have to
> deal with any of the macros and offsets and registration suggested here. Just
> cast the mbuf pointer into the new type mbuf structure. We just have to make
> sure the code that needs to use a given mbuf type has access to the structure
> definitions.
>
> With the current proposal, we can imagine an API to ask to register a
> field at a specific offset. It can then be used in the application, so
> that accesses are done at no cost compared to a static field, because
> the offset would be const.
>
> In the driver, the same logic could be used, but dynamically:
>
> if (offset == PREFERRED_OFFSET) {
> /* code with static offset */
> } else {
> /* generic code */
> }
>
> But I'm not sure it would scale a lot if there are several features
> using dynamic fields.
>
> > If the mbufs it going to be translated from one type mbuf to another mbuf
> > type, we just have to define that type and then cast the mbuf pointer to that
> > structure. When an mbuf is received from IPSec PMD then the application needs
> > to forward that mbuf to the next stage it can reset the type to 0 or to
> > another type filling in the reserved fields to be used by the next stage in
> > the pipeline.
>
> What you describe is one use case.
>
> What could be done with the API mentionned above (but I think it is
> dangerous), is to allow a user to register 2 different fields at the
> same offset, using a specific flag. This could work if the user knows
> that these 2 fields are never used at the same time.
>
> The mbuf now contains the type and every point in the application can look at
> the type to determine how that mbuf is defined. I am sure there are some holes
> here, but I think it is a better solution then using all of these macros,
> offset values and registration APIs.
>
> I'm not convinced having selective layouts is doable. The layouts cannot
> fit all possible use cases, and managing the different layouts in the
> driver looks difficult to me. Additionnaly, it does not solve the
> problem of mutually exclusive features.
>
> I too at one time wanted some type of allocation or registration for
> private mbuf space and applying to these limited fields in the mbuf
> header may have been reasonable. The problem is using registration and
> moving that information between processes is going to be hard to get
> right. For a single Appliance model application it would work great
> and not in a non-appliance model applications.
I didn't get why it wouldn't work in a non-appliance model (are you
talking about primary/secondary processes?). Can you elaborate about
waht would be the problem?
> The type/structure
> method can help and it could have problems too, but using a
> type/struct design seems to be one of the BKMs (Best Known Methods) in
> the industry.
Sorry, but this is not a valid argument.
> To be honest it maybe we just take the hit in performance and add a
> third cache line as I am sure trying to squeeze metadata into these
> very limit fields will be a challenge IMO. I am not suggesting we add
> a cache line to every mbuf only to the pools that require the extra
> metadata by using the private space if that is reasonable. The
> applications needing a lot of metadata will just have to take the hit
> in performance anyway.
If an application wants to attach more data in the mbuf, we already have
the application private area. This zone is transparent from DPDK point
of view, it does not impact drivers or libs.
> Having to grab a metadata value via a set of macros and inline
> functions seems like it will consume more cycles then just a
> type/structure method as the compiler will help optimize the code
> without having to call any macros or inline functions.
Yes, I know that. This is the price to pay for solving the problems
(wasted size, exclusive features, avoid abi breakage). I answered in a
previous mail that the extra cost can be removed at application level if
we add an API to reserve a known offset. The ability to locate some
offload fields in the Rx part may also help to gain some cycles compared
to static fields.
Regards,
Olivier
> On Sep 23, 2019, at 11:16 AM, Olivier Matz <olivier.matz@6wind.com> wrote:
>
> Hi,
>
> (reformated the quotes)
>
> On Mon, Sep 23, 2019 at 03:14:51PM +0000, Wiles, Keith wrote:
>>
>>
>> On Sep 23, 2019, at 4:13 AM, Olivier Matz <olivier.matz@6wind.com<mailto:olivier.matz@6wind.com>> wrote:
>>>
>>> Hi Keith,
>>>
>>> On Sat, Sep 21, 2019 at 08:28:32AM +0000, Wiles, Keith wrote:
>>>>
>>>>
>>>> On Sep 18, 2019, at 6:54 PM, Olivier Matz <olivier.matz@6wind.com<mailto:olivier.matz@6wind.com>> wrote:
>>>>
>>>>> 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<mailto:olivier.matz@6wind.com>>
>>>>> Acked-by: Thomas Monjalon <thomas@monjalon.net<mailto:thomas@monjalon.net>>
>>>> —
>>>>
>>>>
>>>>
>>>> The idea of registration for space in the mbuf I am not a big fan. I did like
>>>> Konstantin’s suggestion of having the compiler help with optimizing the code,
>>>> but with a slight difference. Maybe I misunderstand, but now with this design
>>>> you have to pass the offsets to different parts of the application or place in
>>>> global memory or have each section request the offsets. It seems great if the
>>>> application is one big application or an appliance model application having
>>>> control of the whole design not so good for service chains like designs where
>>>> different parts of the whole application is design by different teams.
>>>
>>> If the global variable storing the offset is defined in the mbuf layer, what
>>> would be the problem?
>>
>> Are you assuming the values are shared between primary/secondary model or
>> between processes using shared memory? If moving the packet data via shared
>> memory to a different application written by a different company you still
>> have to move that metadata.
>
> The dynamic mbuf proposal works with secondary processes. What does that
> change if the application is written by a different company? If you need
> to store a timestamp, you register the timestamp and the offset will be
> the same in primary and secondary.
>
>
>> If the type was carried with the mbuf we can easily convey a small
>> type value or we would need to tell the other side we have all of this
>> registration information to send. I would suggest the number of mbuf
>> types will be small over time and I believe a 4 bit or 8 bit type is
>> reasonable. In many protocols using a type value is used to convey
>> this type of information. We can even tightly control the number of
>> types DPDK controls and then leave some for user defined if we like.
>
> 8 bits means 256 different mbuf layouts.
I also stated 4 bits, but it is a problem with using types we have to allow a number of them, but the smart thing is we restrict DPDK uses to only a few. The developer of other applications using DPDK can use any number they need.
> You did not replied to my previous questions:
Sorry I did not see a question other than a statement wrapped in a question.
The reply to the your question about storing the offsets in the mbuf layer is just extra data and APIs we have to test. The mbuf pool would have to carry this information or some way to associate the metadata of the metadata to the given mbuf. My point is the type is carried with the mbuf and then we have no question as to the type of metadata contained in the mbuf. Having metadata for the metadata for the application to grab or use even more macros or inlines its not going to make it easier for the developer only more complex. A type field will tell you exactly what and were the metadata is located in the mbuf header.
>
> - what happens if you need a field from layout1 and another from layout2?
> (ex: timestamp + ipsec, timestamp + seqn, seqn + ipsec, …)
At this point you need to be smart and use a single type instead of trying to merge two or three types or use cases. The type defines the valid fields, if we are changing the fields from one to another in a single mbuf instance or packet instance that will not happen in the cases you defined above. Multi-mbufs from say a PMD or application is not going to need to combine all of the above examples.
> - how do you implement the rx/tx drivers functions if you have to support
> several layouts, where a field may be at a different offset?
>
>>>> The only things you would have to do is:
>>>>
>>>> 1/ ensure the offset is registered
>>>> rte_mbuf_dyn_timestamp_register()
>>>>
>>>> 2/ use helpers
>>>> rte_mbuf_dyn_timestamp_get(), rte_mbuf_dyn_timestamp_set(), ...
>>
>>> Konstantin’s suggest if I understand it was to use structures to allow the
>>> compiler to optimize the access to the mbuf and I like that idea, but with one
>>> change we add a field in the mbuf to define the mbuf structure type.
>>>
>>> Say 0 is the standard rte_mbuf type then type 1 could be the IPSec offset type
>>> mbuf, type 2 could be something else, … The type 0 looks just like the mbuf we
>>> have today with maybe the optional fields set to reserved or some type of
>>> filler variables to reserve the holes in the structure. Then type 1 is the
>>> IPSec mbuf and in the reserved sections of the mbuf contain the IPSec related
>>> data with the standard mbuf fields still matching the type 0 version.
>>
>> This very look like the "selective layout" in our presentation [1], page 14.
>>
>> Your example talks about IPsec, but someone else will want to use a
>> sequence number, another one a timestamp, and another one will want to
>> use this space for its own application. There are a lot of use cases,
>> and it does not scale to have a layout for each of them. Worst, if
>> someone wants IPsec + a sequence number, how can it work?
>>
>> One of the problem to solve is to avoid mutually exclusive feature (i.e.
>> union of fields that cannot be used together in the mbuf).
>>
>> This allows the mbuf to be used by the developer and the compiler now knows
>> exactly where the fields are located in the structure and does not have to
>> deal with any of the macros and offsets and registration suggested here. Just
>> cast the mbuf pointer into the new type mbuf structure. We just have to make
>> sure the code that needs to use a given mbuf type has access to the structure
>> definitions.
>>
>> With the current proposal, we can imagine an API to ask to register a
>> field at a specific offset. It can then be used in the application, so
>> that accesses are done at no cost compared to a static field, because
>> the offset would be const.
>>
>> In the driver, the same logic could be used, but dynamically:
>>
>> if (offset == PREFERRED_OFFSET) {
>> /* code with static offset */
>> } else {
>> /* generic code */
>> }
>>
>> But I'm not sure it would scale a lot if there are several features
>> using dynamic fields.
>>
>>> If the mbufs it going to be translated from one type mbuf to another mbuf
>>> type, we just have to define that type and then cast the mbuf pointer to that
>>> structure. When an mbuf is received from IPSec PMD then the application needs
>>> to forward that mbuf to the next stage it can reset the type to 0 or to
>>> another type filling in the reserved fields to be used by the next stage in
>>> the pipeline.
>>
>> What you describe is one use case.
>>
>> What could be done with the API mentionned above (but I think it is
>> dangerous), is to allow a user to register 2 different fields at the
>> same offset, using a specific flag. This could work if the user knows
>> that these 2 fields are never used at the same time.
>>
>> The mbuf now contains the type and every point in the application can look at
>> the type to determine how that mbuf is defined. I am sure there are some holes
>> here, but I think it is a better solution then using all of these macros,
>> offset values and registration APIs.
>>
>> I'm not convinced having selective layouts is doable. The layouts cannot
>> fit all possible use cases, and managing the different layouts in the
>> driver looks difficult to me. Additionnaly, it does not solve the
>> problem of mutually exclusive features.
>>
>> I too at one time wanted some type of allocation or registration for
>> private mbuf space and applying to these limited fields in the mbuf
>> header may have been reasonable. The problem is using registration and
>> moving that information between processes is going to be hard to get
>> right. For a single Appliance model application it would work great
>> and not in a non-appliance model applications.
>
> I didn't get why it wouldn't work in a non-appliance model (are you
> talking about primary/secondary processes?). Can you elaborate about
> waht would be the problem?
Let's look at something similar to VPP with nodes in a graph where each node needs to verify the metadata exists in that packet (extra macro/inline calls). This would be needed for every packet processed unless something else make sure only specific mbuf type is used. Why not just use a type field and cast the mbuf into the correct type structure and reject any mbufs that do not match the types that can be handled by this node. The type field would be a simple switch or if/else construct.
>
>> The type/structure
>> method can help and it could have problems too, but using a
>> type/struct design seems to be one of the BKMs (Best Known Methods) in
>> the industry.
>
> Sorry, but this is not a valid argument.
You assumption is not valid IMO. Sorry.
>> To be honest it maybe we just take the hit in performance and add a
>> third cache line as I am sure trying to squeeze metadata into these
>> very limit fields will be a challenge IMO. I am not suggesting we add
>> a cache line to every mbuf only to the pools that require the extra
>> metadata by using the private space if that is reasonable. The
>> applications needing a lot of metadata will just have to take the hit
>> in performance anyway.
>
> If an application wants to attach more data in the mbuf, we already have
> the application private area. This zone is transparent from DPDK point
> of view, it does not impact drivers or libs.
We still have to have all parts of the system which accesses the metadata to know the private data exist and what it's given format. You solved this with offsets and registration to define the format. My suggestion is similar as it defines the location and type of metadata in a type/struct format. I feel it is easier to understand and too process in a high performance way.
>
>> Having to grab a metadata value via a set of macros and inline
>> functions seems like it will consume more cycles then just a
>> type/structure method as the compiler will help optimize the code
>> without having to call any macros or inline functions.
>
> Yes, I know that. This is the price to pay for solving the problems
> (wasted size, exclusive features, avoid abi breakage). I answered in a
> previous mail that the extra cost can be removed at application level if
> we add an API to reserve a known offset. The ability to locate some
> offload fields in the Rx part may also help to gain some cycles compared
> to static fields.
This maybe true, but I do not see how the cycles can be removed unless you create a structure layout in the application to access the metadata. Just saying it can be solved is OK, but proving it can be solved is the real question.
Anyway I am not going to argue with you, the community can decide if your solution solves the problem. In my case I do not see it solving it in the best way and my suggestion may not be the best either.
>
> Regards,
> Olivier
Regards,
Keith
Hi Olivier,
> 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.
Looks ok to me in general.
Some comments/suggestions inline.
Konstantin
>
> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> Acked-by: Thomas Monjalon <thomas@monjalon.net>
> ---
>
> 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 | 114 ++++++-
> 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 | 25 +-
> lib/librte_mbuf/rte_mbuf_dyn.c | 408 +++++++++++++++++++++++++
> lib/librte_mbuf/rte_mbuf_dyn.h | 163 ++++++++++
> lib/librte_mbuf/rte_mbuf_version.map | 4 +
> 8 files changed, 724 insertions(+), 5 deletions(-)
> create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.c
> create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.h
>
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -198,9 +198,12 @@ extern "C" {
> #define PKT_RX_OUTER_L4_CKSUM_GOOD (1ULL << 22)
> #define PKT_RX_OUTER_L4_CKSUM_INVALID ((1ULL << 21) | (1ULL << 22))
>
> -/* add new RX flags here */
> +/* add new RX flags here, don't forget to update PKT_FIRST_FREE */
>
> -/* add new TX flags here */
> +#define PKT_FIRST_FREE (1ULL << 23)
> +#define PKT_LAST_FREE (1ULL << 39)
> +
> +/* add new TX flags here, don't forget to update PKT_LAST_FREE */
>
> /**
> * Indicate that the metadata field in the mbuf is in use.
> @@ -738,6 +741,8 @@ struct rte_mbuf {
> */
> struct rte_mbuf_ext_shared_info *shinfo;
>
> + uint64_t dynfield1; /**< Reserved for dynamic fields. */
> + uint64_t dynfield2; /**< Reserved for dynamic fields. */
Wonder why just not one field:
union {
uint8_t u8[16];
...
uint64_t u64[2];
} dyn_field1;
?
Probably would be a bit handy, to refer, register, etc. no?
> } __rte_cache_aligned;
>
> /**
> @@ -1684,6 +1689,21 @@ rte_pktmbuf_attach_extbuf(struct rte_mbuf *m, void *buf_addr,
> */
> #define rte_pktmbuf_detach_extbuf(m) rte_pktmbuf_detach(m)
>
> +/**
> + * Copy dynamic fields from m_src to m_dst.
> + *
> + * @param m_dst
> + * The destination mbuf.
> + * @param m_src
> + * The source mbuf.
> + */
> +static inline void
> +rte_mbuf_dynfield_copy(struct rte_mbuf *m_dst, const struct rte_mbuf *m_src)
> +{
> + m_dst->dynfield1 = m_src->dynfield1;
> + m_dst->dynfield2 = m_src->dynfield2;
> +}
> +
> /**
> * Attach packet mbuf to another packet mbuf.
> *
> @@ -1732,6 +1752,7 @@ static inline void rte_pktmbuf_attach(struct rte_mbuf *mi, struct rte_mbuf *m)
> mi->vlan_tci_outer = m->vlan_tci_outer;
> mi->tx_offload = m->tx_offload;
> mi->hash = m->hash;
> + rte_mbuf_dynfield_copy(mi, m);
>
> mi->next = NULL;
> mi->pkt_len = mi->data_len;
> diff --git a/lib/librte_mbuf/rte_mbuf_dyn.c b/lib/librte_mbuf/rte_mbuf_dyn.c
> new file mode 100644
> index 000000000..13b8742d0
> --- /dev/null
> +++ b/lib/librte_mbuf/rte_mbuf_dyn.c
> @@ -0,0 +1,408 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright 2019 6WIND S.A.
> + */
> +
> +#include <sys/queue.h>
> +
> +#include <rte_common.h>
> +#include <rte_eal.h>
> +#include <rte_eal_memconfig.h>
> +#include <rte_tailq.h>
> +#include <rte_errno.h>
> +#include <rte_malloc.h>
> +#include <rte_string_fns.h>
> +#include <rte_mbuf.h>
> +#include <rte_mbuf_dyn.h>
> +
> +#define RTE_MBUF_DYN_MZNAME "rte_mbuf_dyn"
> +
> +struct mbuf_dynfield_elt {
> + TAILQ_ENTRY(mbuf_dynfield_elt) next;
> + struct rte_mbuf_dynfield params;
> + int offset;
Why not 'size_t offset', to avoid any explicit conversions, etc?
> +};
> +TAILQ_HEAD(mbuf_dynfield_list, rte_tailq_entry);
> +
> +static struct rte_tailq_elem mbuf_dynfield_tailq = {
> + .name = "RTE_MBUF_DYNFIELD",
> +};
> +EAL_REGISTER_TAILQ(mbuf_dynfield_tailq);
> +
> +struct mbuf_dynflag_elt {
> + TAILQ_ENTRY(mbuf_dynflag_elt) next;
> + struct rte_mbuf_dynflag params;
> + int bitnum;
> +};
> +TAILQ_HEAD(mbuf_dynflag_list, rte_tailq_entry);
> +
> +static struct rte_tailq_elem mbuf_dynflag_tailq = {
> + .name = "RTE_MBUF_DYNFLAG",
> +};
> +EAL_REGISTER_TAILQ(mbuf_dynflag_tailq);
> +
> +struct mbuf_dyn_shm {
> + /** For each mbuf byte, free_space[i] == 1 if space is free. */
> + uint8_t free_space[sizeof(struct rte_mbuf)];
> + /** Bitfield of available flags. */
> + uint64_t free_flags;
> +};
> +static struct mbuf_dyn_shm *shm;
> +
> +/* allocate and initialize the shared memory */
> +static int
> +init_shared_mem(void)
> +{
> + const struct rte_memzone *mz;
> + uint64_t mask;
> +
> + if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
> + mz = rte_memzone_reserve_aligned(RTE_MBUF_DYN_MZNAME,
> + sizeof(struct mbuf_dyn_shm),
> + SOCKET_ID_ANY, 0,
> + RTE_CACHE_LINE_SIZE);
> + } else {
> + mz = rte_memzone_lookup(RTE_MBUF_DYN_MZNAME);
> + }
> + if (mz == NULL)
> + return -1;
> +
> + shm = mz->addr;
> +
> +#define mark_free(field) \
> + memset(&shm->free_space[offsetof(struct rte_mbuf, field)], \
> + 0xff, sizeof(((struct rte_mbuf *)0)->field))
I think you can avoid defining/unedifying macros here by something like that:
static const struct {
size_t offset;
size_t size;
} dyn_syms[] = {
[0] = {.offset = offsetof(struct rte_mbuf, dynfield1), sizeof((struct rte_mbuf *)0)->dynfield1),
[1] = {.offset = offsetof(struct rte_mbuf, dynfield2), sizeof((struct rte_mbuf *)0)->dynfield2),
};
...
for (i = 0; i != RTE_DIM(dyn_syms); i++)
memset(shm->free_space + dym_syms[i].offset, UINT8_MAX, dym_syms[i].size);
> +
> + if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
> + /* init free_space, keep it sync'd with
> + * rte_mbuf_dynfield_copy().
> + */
> + memset(shm, 0, sizeof(*shm));
> + mark_free(dynfield1);
> + mark_free(dynfield2);
> +
> + /* init free_flags */
> + for (mask = PKT_FIRST_FREE; mask <= PKT_LAST_FREE; mask <<= 1)
> + shm->free_flags |= mask;
> + }
> +#undef mark_free
> +
> + return 0;
> +}
> +
> +/* check if this offset can be used */
> +static int
> +check_offset(size_t offset, size_t size, size_t align, unsigned int flags)
> +{
> + size_t i;
> +
> + (void)flags;
We have RTE_SET_USED() for such cases...
Though as it is an internal function probably better not to introduce
unused parameters at all.
> +
> + if ((offset & (align - 1)) != 0)
> + return -1;
> + if (offset + size > sizeof(struct rte_mbuf))
> + return -1;
> +
> + for (i = 0; i < size; i++) {
> + if (!shm->free_space[i + offset])
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> +/* assume tailq is locked */
> +static struct mbuf_dynfield_elt *
> +__mbuf_dynfield_lookup(const char *name)
> +{
> + struct mbuf_dynfield_list *mbuf_dynfield_list;
> + struct mbuf_dynfield_elt *mbuf_dynfield;
> + struct rte_tailq_entry *te;
> +
> + mbuf_dynfield_list = RTE_TAILQ_CAST(
> + mbuf_dynfield_tailq.head, mbuf_dynfield_list);
> +
> + TAILQ_FOREACH(te, mbuf_dynfield_list, next) {
> + mbuf_dynfield = (struct mbuf_dynfield_elt *)te->data;
> + if (strcmp(name, mbuf_dynfield->params.name) == 0)
> + break;
> + }
> +
> + if (te == NULL) {
> + rte_errno = ENOENT;
> + return NULL;
> + }
> +
> + return mbuf_dynfield;
> +}
> +
> +int
> +rte_mbuf_dynfield_lookup(const char *name, struct rte_mbuf_dynfield *params)
> +{
> + struct mbuf_dynfield_elt *mbuf_dynfield;
> +
> + if (shm == NULL) {
> + rte_errno = ENOENT;
> + return -1;
> + }
> +
> + rte_mcfg_tailq_read_lock();
> + mbuf_dynfield = __mbuf_dynfield_lookup(name);
> + rte_mcfg_tailq_read_unlock();
> +
> + if (mbuf_dynfield == NULL) {
> + rte_errno = ENOENT;
> + return -1;
> + }
> +
> + if (params != NULL)
> + memcpy(params, &mbuf_dynfield->params, sizeof(*params));
> +
> + return mbuf_dynfield->offset;
> +}
> +
> +static int mbuf_dynfield_cmp(const struct rte_mbuf_dynfield *params1,
> + const struct rte_mbuf_dynfield *params2)
> +{
> + if (strcmp(params1->name, params2->name))
> + return -1;
> + if (params1->size != params2->size)
> + return -1;
> + if (params1->align != params2->align)
> + return -1;
> + if (params1->flags != params2->flags)
> + return -1;
> + return 0;
> +}
> +
> +int
> +rte_mbuf_dynfield_register(const struct rte_mbuf_dynfield *params)
What I meant at user-space - if we can also have another function that would allow
user to specify required offset for dynfield explicitly, then user can define it as constant
value and let compiler do optimization work and hopefully generate faster code to access
this field.
Something like that:
int rte_mbuf_dynfiled_register_offset(const struct rte_mbuf_dynfield *params, size_t offset);
#define RTE_MBUF_DYNFIELD_OFFSET(fld, off) (offsetof(struct rte_mbuf, fld) + (off))
And then somewhere in user code:
/* to let say reserve first 4B in dynfield1*/
#define MBUF_DYNFIELD_A RTE_MBUF_DYNFIELD_OFFSET(dynfiled1, 0)
...
params.name = RTE_STR(MBUF_DYNFIELD_A);
params.size = sizeof(uint32_t);
params.align = sizeof(uint32_t);
ret = rte_mbuf_dynfiled_register_offset(¶ms, MBUF_DYNFIELD_A);
if (ret != MBUF_DYNFIELD_A) {
/* handle it somehow, probably just terminate gracefully... */
}
...
/* to let say reserve last 2B in dynfield2*/
#define MBUF_DYNFIELD_B RTE_MBUF_DYNFIELD_OFFSET(dynfiled2, 6)
...
params.name = RTE_STR(MBUF_DYNFIELD_B);
params.size = sizeof(uint16_t);
params.align = sizeof(uint16_t);
ret = rte_mbuf_dynfiled_register_offset(¶ms, MBUF_DYNFIELD_B);
After that user can use constant offsets MBUF_DYNFIELD_A/ MBUF_DYNFIELD_B
to access these fields.
Same thoughts for DYNFLAG.
> +{
> + struct mbuf_dynfield_list *mbuf_dynfield_list;
> + struct mbuf_dynfield_elt *mbuf_dynfield = NULL;
> + struct rte_tailq_entry *te = NULL;
> + int offset, ret;
size_t offset
to avoid explicit conversions, etc.?
> + size_t i;
> +
> + if (shm == NULL && init_shared_mem() < 0)
> + goto fail;
As I understand, here you allocate/initialize your shm without any lock protection,
though later you protect it via rte_mcfg_tailq_write_lock().
That seems a bit flakey to me.
Why not to store information about free dynfield bytes inside mbuf_dynfield_tailq?
Let say at init() create and add an entry into that list with some reserved name.
Then at register - grab mcfg_tailq_write_lock and do lookup
for such entry and then read/update it as needed.
It would help to avoid racing problem, plus you wouldn't need to
allocate/lookup for memzone.
> + if (params->size >= sizeof(struct rte_mbuf)) {
> + rte_errno = EINVAL;
> + goto fail;
> + }
> + if (!rte_is_power_of_2(params->align)) {
> + rte_errno = EINVAL;
> + goto fail;
> + }
> + if (params->flags != 0) {
> + rte_errno = EINVAL;
> + goto fail;
> + }
> +
> + rte_mcfg_tailq_write_lock();
> +
I think it probably would be cleaner and easier to read/maintain, if you'll put actual
code under lock protection into a separate function - as you did for __mbuf_dynfield_lookup().
> + mbuf_dynfield = __mbuf_dynfield_lookup(params->name);
> + if (mbuf_dynfield != NULL) {
> + if (mbuf_dynfield_cmp(params, &mbuf_dynfield->params) < 0) {
> + rte_errno = EEXIST;
> + goto fail_unlock;
> + }
> + offset = mbuf_dynfield->offset;
> + goto out_unlock;
> + }
> +
> + if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
> + rte_errno = EPERM;
> + goto fail_unlock;
> + }
> +
> + for (offset = 0;
> + offset < (int)sizeof(struct rte_mbuf);
> + offset++) {
> + if (check_offset(offset, params->size, params->align,
> + params->flags) == 0)
> + break;
> + }
> +
> + if (offset == sizeof(struct rte_mbuf)) {
> + rte_errno = ENOENT;
> + goto fail_unlock;
> + }
> +
> + mbuf_dynfield_list = RTE_TAILQ_CAST(
> + mbuf_dynfield_tailq.head, mbuf_dynfield_list);
> +
> + te = rte_zmalloc("MBUF_DYNFIELD_TAILQ_ENTRY", sizeof(*te), 0);
> + if (te == NULL)
> + goto fail_unlock;
> +
> + mbuf_dynfield = rte_zmalloc("mbuf_dynfield", sizeof(*mbuf_dynfield), 0);
> + if (mbuf_dynfield == NULL)
> + goto fail_unlock;
> +
> + ret = strlcpy(mbuf_dynfield->params.name, params->name,
> + sizeof(mbuf_dynfield->params.name));
> + if (ret < 0 || ret >= (int)sizeof(mbuf_dynfield->params.name)) {
> + rte_errno = ENAMETOOLONG;
> + goto fail_unlock;
> + }
> + memcpy(&mbuf_dynfield->params, params, sizeof(mbuf_dynfield->params));
> + mbuf_dynfield->offset = offset;
> + te->data = mbuf_dynfield;
> +
> + TAILQ_INSERT_TAIL(mbuf_dynfield_list, te, next);
> +
> + for (i = offset; i < offset + params->size; i++)
> + shm->free_space[i] = 0;
> +
> + RTE_LOG(DEBUG, MBUF, "Registered dynamic field %s (sz=%zu, al=%zu, fl=0x%x) -> %d\n",
> + params->name, params->size, params->align, params->flags,
> + offset);
> +
> +out_unlock:
> + rte_mcfg_tailq_write_unlock();
> +
> + return offset;
> +
> +fail_unlock:
> + rte_mcfg_tailq_write_unlock();
> +fail:
> + rte_free(mbuf_dynfield);
> + rte_free(te);
> + return -1;
> +}
> +
> +/* assume tailq is locked */
> +static struct mbuf_dynflag_elt *
> +__mbuf_dynflag_lookup(const char *name)
> +{
> + struct mbuf_dynflag_list *mbuf_dynflag_list;
> + struct mbuf_dynflag_elt *mbuf_dynflag;
> + struct rte_tailq_entry *te;
> +
> + mbuf_dynflag_list = RTE_TAILQ_CAST(
> + mbuf_dynflag_tailq.head, mbuf_dynflag_list);
> +
> + TAILQ_FOREACH(te, mbuf_dynflag_list, next) {
> + mbuf_dynflag = (struct mbuf_dynflag_elt *)te->data;
> + if (strncmp(name, mbuf_dynflag->params.name,
> + RTE_MBUF_DYN_NAMESIZE) == 0)
> + break;
> + }
> +
> + if (te == NULL) {
> + rte_errno = ENOENT;
> + return NULL;
> + }
> +
> + return mbuf_dynflag;
> +}
> +
> +int
> +rte_mbuf_dynflag_lookup(const char *name,
> + struct rte_mbuf_dynflag *params)
> +{
> + struct mbuf_dynflag_elt *mbuf_dynflag;
> +
> + if (shm == NULL) {
> + rte_errno = ENOENT;
> + return -1;
> + }
> +
> + rte_mcfg_tailq_read_lock();
> + mbuf_dynflag = __mbuf_dynflag_lookup(name);
> + rte_mcfg_tailq_read_unlock();
> +
> + if (mbuf_dynflag == NULL) {
> + rte_errno = ENOENT;
> + return -1;
> + }
> +
> + if (params != NULL)
> + memcpy(params, &mbuf_dynflag->params, sizeof(*params));
> +
> + return mbuf_dynflag->bitnum;
> +}
> +
> +static int mbuf_dynflag_cmp(const struct rte_mbuf_dynflag *params1,
> + const struct rte_mbuf_dynflag *params2)
> +{
> + if (strcmp(params1->name, params2->name))
> + return -1;
> + if (params1->flags != params2->flags)
> + return -1;
> + return 0;
> +}
> +
> +int
> +rte_mbuf_dynflag_register(const struct rte_mbuf_dynflag *params)
> +{
> + struct mbuf_dynflag_list *mbuf_dynflag_list;
> + struct mbuf_dynflag_elt *mbuf_dynflag = NULL;
> + struct rte_tailq_entry *te = NULL;
> + int bitnum, ret;
> +
> + if (shm == NULL && init_shared_mem() < 0)
> + goto fail;
> +
> + rte_mcfg_tailq_write_lock();
> +
> + mbuf_dynflag = __mbuf_dynflag_lookup(params->name);
> + if (mbuf_dynflag != NULL) {
> + if (mbuf_dynflag_cmp(params, &mbuf_dynflag->params) < 0) {
> + rte_errno = EEXIST;
> + goto fail_unlock;
> + }
> + bitnum = mbuf_dynflag->bitnum;
> + goto out_unlock;
> + }
> +
> + if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
> + rte_errno = EPERM;
> + goto fail_unlock;
> + }
> +
> + if (shm->free_flags == 0) {
> + rte_errno = ENOENT;
> + goto fail_unlock;
> + }
> + bitnum = rte_bsf64(shm->free_flags);
> +
> + mbuf_dynflag_list = RTE_TAILQ_CAST(
> + mbuf_dynflag_tailq.head, mbuf_dynflag_list);
> +
> + te = rte_zmalloc("MBUF_DYNFLAG_TAILQ_ENTRY", sizeof(*te), 0);
> + if (te == NULL)
> + goto fail_unlock;
> +
> + mbuf_dynflag = rte_zmalloc("mbuf_dynflag", sizeof(*mbuf_dynflag), 0);
> + if (mbuf_dynflag == NULL)
> + goto fail_unlock;
> +
> + ret = strlcpy(mbuf_dynflag->params.name, params->name,
> + sizeof(mbuf_dynflag->params.name));
> + if (ret < 0 || ret >= (int)sizeof(mbuf_dynflag->params.name)) {
> + rte_errno = ENAMETOOLONG;
> + goto fail_unlock;
> + }
> + mbuf_dynflag->bitnum = bitnum;
> + te->data = mbuf_dynflag;
> +
> + TAILQ_INSERT_TAIL(mbuf_dynflag_list, te, next);
> +
> + shm->free_flags &= ~(1ULL << bitnum);
> +
> + RTE_LOG(DEBUG, MBUF, "Registered dynamic flag %s (fl=0x%x) -> %u\n",
> + params->name, params->flags, bitnum);
> +
> +out_unlock:
> + rte_mcfg_tailq_write_unlock();
> +
> + return bitnum;
> +
> +fail_unlock:
> + rte_mcfg_tailq_write_unlock();
> +fail:
> + rte_free(mbuf_dynflag);
> + rte_free(te);
> + return -1;
> +}
> diff --git a/lib/librte_mbuf/rte_mbuf_dyn.h b/lib/librte_mbuf/rte_mbuf_dyn.h
> new file mode 100644
> index 000000000..6e2c81654
> --- /dev/null
> +++ b/lib/librte_mbuf/rte_mbuf_dyn.h
> @@ -0,0 +1,163 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright 2019 6WIND S.A.
> + */
> +
> +#ifndef _RTE_MBUF_DYN_H_
> +#define _RTE_MBUF_DYN_H_
> +
> +/**
> + * @file
> + * RTE Mbuf 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 module addresses this issue, 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, stored
> + * in mbuf->ol_flags.
> + *
> + * The typical use case is when a specific offload feature requires to
> + * register a dedicated offload field in the mbuf structure, and adding
> + * a static field or flag is not justified.
> + *
> + * Example of use:
> + *
> + * - A rte_mbuf_dynfield structure is defined, containing the parameters
> + * of the dynamic field to be registered:
> + * const struct rte_mbuf_dynfield rte_dynfield_my_feature = { ... };
> + * - The application initializes the PMD, and asks for this feature
> + * at port initialization by passing DEV_RX_OFFLOAD_MY_FEATURE in
> + * rxconf. This will make the PMD to register the field by calling
> + * rte_mbuf_dynfield_register(&rte_dynfield_my_feature). The PMD
> + * stores the returned offset.
> + * - The application that uses the offload feature also registers
> + * the field to retrieve the same offset.
> + * - When the PMD receives a packet, it can set the field:
> + * *RTE_MBUF_DYNFIELD(m, offset, <type *>) = value;
> + * - In the main loop, the application can retrieve the value with
> + * the same macro.
> + *
> + * To avoid wasting space, the dynamic fields or flags must only be
> + * reserved on demand, when an application asks for the related feature.
> + *
> + * The registration can be done at any moment, but it is not possible
> + * to unregister fields or flags for now.
> + *
> + * A dynamic field can be reserved and used by an application only.
> + * It can for instance be a packet mark.
> + */
> +
> +#include <sys/types.h>
> +/**
> + * Maximum length of the dynamic field or flag string.
> + */
> +#define RTE_MBUF_DYN_NAMESIZE 64
> +
> +/**
> + * Structure describing the parameters of a mbuf dynamic field.
> + */
> +struct rte_mbuf_dynfield {
> + char name[RTE_MBUF_DYN_NAMESIZE]; /**< Name of the field. */
> + size_t size; /**< The number of bytes to reserve. */
> + size_t align; /**< The alignment constraint (power of 2). */
> + unsigned int flags; /**< Reserved for future use, must be 0. */
> +};
> +
> +/**
> + * Structure describing the parameters of a mbuf dynamic flag.
> + */
> +struct rte_mbuf_dynflag {
> + char name[RTE_MBUF_DYN_NAMESIZE]; /**< Name of the dynamic flag. */
> + unsigned int flags; /**< Reserved for future use, must be 0. */
> +};
> +
> +/**
> + * Register space for a dynamic field in the mbuf structure.
> + *
> + * If the field is already registered (same name and parameters), its
> + * offset is returned.
> + *
> + * @param params
> + * A structure containing the requested parameters (name, size,
> + * alignment constraint and flags).
> + * @return
> + * The offset in the mbuf structure, or -1 on error.
> + * Possible values for rte_errno:
> + * - EINVAL: invalid parameters (size, align, or flags).
> + * - EEXIST: this name is already register with different parameters.
> + * - EPERM: called from a secondary process.
> + * - ENOENT: not enough room in mbuf.
> + * - ENOMEM: allocation failure.
> + * - ENAMETOOLONG: name does not ends with \0.
> + */
> +__rte_experimental
> +int rte_mbuf_dynfield_register(const struct rte_mbuf_dynfield *params);
> +
> +/**
> + * Lookup for a registered dynamic mbuf field.
> + *
> + * @param name
> + * A string identifying the dynamic field.
> + * @param params
> + * If not NULL, and if the lookup is successful, the structure is
> + * filled with the parameters of the dynamic field.
> + * @return
> + * The offset of this field in the mbuf structure, or -1 on error.
> + * Possible values for rte_errno:
> + * - ENOENT: no dynamic field matches this name.
> + */
> +__rte_experimental
> +int rte_mbuf_dynfield_lookup(const char *name,
> + struct rte_mbuf_dynfield *params);
> +
> +/**
> + * Register a dynamic flag in the mbuf structure.
> + *
> + * If the flag is already registered (same name and parameters), its
> + * offset is returned.
> + *
> + * @param params
> + * A structure containing the requested parameters of the dynamic
> + * flag (name and options).
> + * @return
> + * The number of the reserved bit, or -1 on error.
> + * Possible values for rte_errno:
> + * - EINVAL: invalid parameters (size, align, or flags).
> + * - EEXIST: this name is already register with different parameters.
> + * - EPERM: called from a secondary process.
> + * - ENOENT: no more flag available.
> + * - ENOMEM: allocation failure.
> + * - ENAMETOOLONG: name is longer than RTE_MBUF_DYN_NAMESIZE - 1.
> + */
> +__rte_experimental
> +int rte_mbuf_dynflag_register(const struct rte_mbuf_dynflag *params);
> +
> +/**
> + * Lookup for a registered dynamic mbuf flag.
> + *
> + * @param name
> + * A string identifying the dynamic flag.
> + * @param params
> + * If not NULL, and if the lookup is successful, the structure is
> + * filled with the parameters of the dynamic flag.
> + * @return
> + * The offset of this flag in the mbuf structure, or -1 on error.
> + * Possible values for rte_errno:
> + * - ENOENT: no dynamic flag matches this name.
> + */
> +__rte_experimental
> +int rte_mbuf_dynflag_lookup(const char *name,
> + struct rte_mbuf_dynflag *params);
> +
> +/**
> + * Helper macro to access to a dynamic field.
> + */
> +#define RTE_MBUF_DYNFIELD(m, offset, type) ((type)((uintptr_t)(m) + (offset)))
> +
> +#endif
> diff --git a/lib/librte_mbuf/rte_mbuf_version.map b/lib/librte_mbuf/rte_mbuf_version.map
> index 2662a37bf..a98310570 100644
> --- a/lib/librte_mbuf/rte_mbuf_version.map
> +++ b/lib/librte_mbuf/rte_mbuf_version.map
> @@ -50,4 +50,8 @@ EXPERIMENTAL {
> global:
>
> rte_mbuf_check;
> + rte_mbuf_dynfield_lookup;
> + rte_mbuf_dynfield_register;
> + rte_mbuf_dynflag_lookup;
> + rte_mbuf_dynflag_register;
> } DPDK_18.08;
> --
> 2.20.1
Hi Konstantin,
Thanks for the feedback. Please see my answers below.
On Tue, Oct 01, 2019 at 10:49:39AM +0000, Ananyev, Konstantin wrote:
> Hi Olivier,
>
> > 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.
>
> Looks ok to me in general.
> Some comments/suggestions inline.
> Konstantin
>
> >
> > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> > Acked-by: Thomas Monjalon <thomas@monjalon.net>
> > ---
> >
> > 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 | 114 ++++++-
> > 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 | 25 +-
> > lib/librte_mbuf/rte_mbuf_dyn.c | 408 +++++++++++++++++++++++++
> > lib/librte_mbuf/rte_mbuf_dyn.h | 163 ++++++++++
> > lib/librte_mbuf/rte_mbuf_version.map | 4 +
> > 8 files changed, 724 insertions(+), 5 deletions(-)
> > create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.c
> > create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.h
> >
> > --- a/lib/librte_mbuf/rte_mbuf.h
> > +++ b/lib/librte_mbuf/rte_mbuf.h
> > @@ -198,9 +198,12 @@ extern "C" {
> > #define PKT_RX_OUTER_L4_CKSUM_GOOD (1ULL << 22)
> > #define PKT_RX_OUTER_L4_CKSUM_INVALID ((1ULL << 21) | (1ULL << 22))
> >
> > -/* add new RX flags here */
> > +/* add new RX flags here, don't forget to update PKT_FIRST_FREE */
> >
> > -/* add new TX flags here */
> > +#define PKT_FIRST_FREE (1ULL << 23)
> > +#define PKT_LAST_FREE (1ULL << 39)
> > +
> > +/* add new TX flags here, don't forget to update PKT_LAST_FREE */
> >
> > /**
> > * Indicate that the metadata field in the mbuf is in use.
> > @@ -738,6 +741,8 @@ struct rte_mbuf {
> > */
> > struct rte_mbuf_ext_shared_info *shinfo;
> >
> > + uint64_t dynfield1; /**< Reserved for dynamic fields. */
> > + uint64_t dynfield2; /**< Reserved for dynamic fields. */
>
> Wonder why just not one field:
> union {
> uint8_t u8[16];
> ...
> uint64_t u64[2];
> } dyn_field1;
> ?
> Probably would be a bit handy, to refer, register, etc. no?
I didn't find any place where we need an access through u8, so I
just changed it into uint64_t dynfield1[2].
>
> > } __rte_cache_aligned;
> >
> > /**
> > @@ -1684,6 +1689,21 @@ rte_pktmbuf_attach_extbuf(struct rte_mbuf *m, void *buf_addr,
> > */
> > #define rte_pktmbuf_detach_extbuf(m) rte_pktmbuf_detach(m)
> >
> > +/**
> > + * Copy dynamic fields from m_src to m_dst.
> > + *
> > + * @param m_dst
> > + * The destination mbuf.
> > + * @param m_src
> > + * The source mbuf.
> > + */
> > +static inline void
> > +rte_mbuf_dynfield_copy(struct rte_mbuf *m_dst, const struct rte_mbuf *m_src)
> > +{
> > + m_dst->dynfield1 = m_src->dynfield1;
> > + m_dst->dynfield2 = m_src->dynfield2;
> > +}
> > +
> > /**
> > * Attach packet mbuf to another packet mbuf.
> > *
> > @@ -1732,6 +1752,7 @@ static inline void rte_pktmbuf_attach(struct rte_mbuf *mi, struct rte_mbuf *m)
> > mi->vlan_tci_outer = m->vlan_tci_outer;
> > mi->tx_offload = m->tx_offload;
> > mi->hash = m->hash;
> > + rte_mbuf_dynfield_copy(mi, m);
> >
> > mi->next = NULL;
> > mi->pkt_len = mi->data_len;
> > diff --git a/lib/librte_mbuf/rte_mbuf_dyn.c b/lib/librte_mbuf/rte_mbuf_dyn.c
> > new file mode 100644
> > index 000000000..13b8742d0
> > --- /dev/null
> > +++ b/lib/librte_mbuf/rte_mbuf_dyn.c
> > @@ -0,0 +1,408 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright 2019 6WIND S.A.
> > + */
> > +
> > +#include <sys/queue.h>
> > +
> > +#include <rte_common.h>
> > +#include <rte_eal.h>
> > +#include <rte_eal_memconfig.h>
> > +#include <rte_tailq.h>
> > +#include <rte_errno.h>
> > +#include <rte_malloc.h>
> > +#include <rte_string_fns.h>
> > +#include <rte_mbuf.h>
> > +#include <rte_mbuf_dyn.h>
> > +
> > +#define RTE_MBUF_DYN_MZNAME "rte_mbuf_dyn"
> > +
> > +struct mbuf_dynfield_elt {
> > + TAILQ_ENTRY(mbuf_dynfield_elt) next;
> > + struct rte_mbuf_dynfield params;
> > + int offset;
>
> Why not 'size_t offset', to avoid any explicit conversions, etc?
Fixed
> > +};
> > +TAILQ_HEAD(mbuf_dynfield_list, rte_tailq_entry);
> > +
> > +static struct rte_tailq_elem mbuf_dynfield_tailq = {
> > + .name = "RTE_MBUF_DYNFIELD",
> > +};
> > +EAL_REGISTER_TAILQ(mbuf_dynfield_tailq);
> > +
> > +struct mbuf_dynflag_elt {
> > + TAILQ_ENTRY(mbuf_dynflag_elt) next;
> > + struct rte_mbuf_dynflag params;
> > + int bitnum;
> > +};
> > +TAILQ_HEAD(mbuf_dynflag_list, rte_tailq_entry);
> > +
> > +static struct rte_tailq_elem mbuf_dynflag_tailq = {
> > + .name = "RTE_MBUF_DYNFLAG",
> > +};
> > +EAL_REGISTER_TAILQ(mbuf_dynflag_tailq);
> > +
> > +struct mbuf_dyn_shm {
> > + /** For each mbuf byte, free_space[i] == 1 if space is free. */
> > + uint8_t free_space[sizeof(struct rte_mbuf)];
> > + /** Bitfield of available flags. */
> > + uint64_t free_flags;
> > +};
> > +static struct mbuf_dyn_shm *shm;
> > +
> > +/* allocate and initialize the shared memory */
> > +static int
> > +init_shared_mem(void)
> > +{
> > + const struct rte_memzone *mz;
> > + uint64_t mask;
> > +
> > + if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
> > + mz = rte_memzone_reserve_aligned(RTE_MBUF_DYN_MZNAME,
> > + sizeof(struct mbuf_dyn_shm),
> > + SOCKET_ID_ANY, 0,
> > + RTE_CACHE_LINE_SIZE);
> > + } else {
> > + mz = rte_memzone_lookup(RTE_MBUF_DYN_MZNAME);
> > + }
> > + if (mz == NULL)
> > + return -1;
> > +
> > + shm = mz->addr;
> > +
> > +#define mark_free(field) \
> > + memset(&shm->free_space[offsetof(struct rte_mbuf, field)], \
> > + 0xff, sizeof(((struct rte_mbuf *)0)->field))
>
> I think you can avoid defining/unedifying macros here by something like that:
>
> static const struct {
> size_t offset;
> size_t size;
> } dyn_syms[] = {
> [0] = {.offset = offsetof(struct rte_mbuf, dynfield1), sizeof((struct rte_mbuf *)0)->dynfield1),
> [1] = {.offset = offsetof(struct rte_mbuf, dynfield2), sizeof((struct rte_mbuf *)0)->dynfield2),
> };
> ...
>
> for (i = 0; i != RTE_DIM(dyn_syms); i++)
> memset(shm->free_space + dym_syms[i].offset, UINT8_MAX, dym_syms[i].size);
>
I tried it, but the following lines are too long
[0] = {offsetof(struct rte_mbuf, dynfield1), sizeof((struct rte_mbuf *)0)->dynfield1),
[1] = {offsetof(struct rte_mbuf, dynfield2), sizeof((struct rte_mbuf *)0)->dynfield2),
To make them shorter, we can use a macro... but... wait :)
> > +
> > + if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
> > + /* init free_space, keep it sync'd with
> > + * rte_mbuf_dynfield_copy().
> > + */
> > + memset(shm, 0, sizeof(*shm));
> > + mark_free(dynfield1);
> > + mark_free(dynfield2);
> > +
> > + /* init free_flags */
> > + for (mask = PKT_FIRST_FREE; mask <= PKT_LAST_FREE; mask <<= 1)
> > + shm->free_flags |= mask;
> > + }
> > +#undef mark_free
> > +
> > + return 0;
> > +}
> > +
> > +/* check if this offset can be used */
> > +static int
> > +check_offset(size_t offset, size_t size, size_t align, unsigned int flags)
> > +{
> > + size_t i;
> > +
> > + (void)flags;
>
>
> We have RTE_SET_USED() for such cases...
> Though as it is an internal function probably better not to introduce
> unused parameters at all.
I removed the flag parameter as you suggested.
> > +
> > + if ((offset & (align - 1)) != 0)
> > + return -1;
> > + if (offset + size > sizeof(struct rte_mbuf))
> > + return -1;
> > +
> > + for (i = 0; i < size; i++) {
> > + if (!shm->free_space[i + offset])
> > + return -1;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +/* assume tailq is locked */
> > +static struct mbuf_dynfield_elt *
> > +__mbuf_dynfield_lookup(const char *name)
> > +{
> > + struct mbuf_dynfield_list *mbuf_dynfield_list;
> > + struct mbuf_dynfield_elt *mbuf_dynfield;
> > + struct rte_tailq_entry *te;
> > +
> > + mbuf_dynfield_list = RTE_TAILQ_CAST(
> > + mbuf_dynfield_tailq.head, mbuf_dynfield_list);
> > +
> > + TAILQ_FOREACH(te, mbuf_dynfield_list, next) {
> > + mbuf_dynfield = (struct mbuf_dynfield_elt *)te->data;
> > + if (strcmp(name, mbuf_dynfield->params.name) == 0)
> > + break;
> > + }
> > +
> > + if (te == NULL) {
> > + rte_errno = ENOENT;
> > + return NULL;
> > + }
> > +
> > + return mbuf_dynfield;
> > +}
> > +
> > +int
> > +rte_mbuf_dynfield_lookup(const char *name, struct rte_mbuf_dynfield *params)
> > +{
> > + struct mbuf_dynfield_elt *mbuf_dynfield;
> > +
> > + if (shm == NULL) {
> > + rte_errno = ENOENT;
> > + return -1;
> > + }
> > +
> > + rte_mcfg_tailq_read_lock();
> > + mbuf_dynfield = __mbuf_dynfield_lookup(name);
> > + rte_mcfg_tailq_read_unlock();
> > +
> > + if (mbuf_dynfield == NULL) {
> > + rte_errno = ENOENT;
> > + return -1;
> > + }
> > +
> > + if (params != NULL)
> > + memcpy(params, &mbuf_dynfield->params, sizeof(*params));
> > +
> > + return mbuf_dynfield->offset;
> > +}
> > +
> > +static int mbuf_dynfield_cmp(const struct rte_mbuf_dynfield *params1,
> > + const struct rte_mbuf_dynfield *params2)
> > +{
> > + if (strcmp(params1->name, params2->name))
> > + return -1;
> > + if (params1->size != params2->size)
> > + return -1;
> > + if (params1->align != params2->align)
> > + return -1;
> > + if (params1->flags != params2->flags)
> > + return -1;
> > + return 0;
> > +}
> > +
> > +int
> > +rte_mbuf_dynfield_register(const struct rte_mbuf_dynfield *params)
>
> What I meant at user-space - if we can also have another function that would allow
> user to specify required offset for dynfield explicitly, then user can define it as constant
> value and let compiler do optimization work and hopefully generate faster code to access
> this field.
> Something like that:
>
> int rte_mbuf_dynfiled_register_offset(const struct rte_mbuf_dynfield *params, size_t offset);
>
> #define RTE_MBUF_DYNFIELD_OFFSET(fld, off) (offsetof(struct rte_mbuf, fld) + (off))
>
> And then somewhere in user code:
>
> /* to let say reserve first 4B in dynfield1*/
> #define MBUF_DYNFIELD_A RTE_MBUF_DYNFIELD_OFFSET(dynfiled1, 0)
> ...
> params.name = RTE_STR(MBUF_DYNFIELD_A);
> params.size = sizeof(uint32_t);
> params.align = sizeof(uint32_t);
> ret = rte_mbuf_dynfiled_register_offset(¶ms, MBUF_DYNFIELD_A);
> if (ret != MBUF_DYNFIELD_A) {
> /* handle it somehow, probably just terminate gracefully... */
> }
> ...
>
> /* to let say reserve last 2B in dynfield2*/
> #define MBUF_DYNFIELD_B RTE_MBUF_DYNFIELD_OFFSET(dynfiled2, 6)
> ...
> params.name = RTE_STR(MBUF_DYNFIELD_B);
> params.size = sizeof(uint16_t);
> params.align = sizeof(uint16_t);
> ret = rte_mbuf_dynfiled_register_offset(¶ms, MBUF_DYNFIELD_B);
>
> After that user can use constant offsets MBUF_DYNFIELD_A/ MBUF_DYNFIELD_B
> to access these fields.
> Same thoughts for DYNFLAG.
I added the feature in v2.
> > + struct mbuf_dynfield_list *mbuf_dynfield_list;
> > + struct mbuf_dynfield_elt *mbuf_dynfield = NULL;
> > + struct rte_tailq_entry *te = NULL;
> > + int offset, ret;
>
> size_t offset
> to avoid explicit conversions, etc.?
>
Fixed.
> > + size_t i;
> > +
> > + if (shm == NULL && init_shared_mem() < 0)
> > + goto fail;
>
> As I understand, here you allocate/initialize your shm without any lock protection,
> though later you protect it via rte_mcfg_tailq_write_lock().
> That seems a bit flakey to me.
> Why not to store information about free dynfield bytes inside mbuf_dynfield_tailq?
> Let say at init() create and add an entry into that list with some reserved name.
> Then at register - grab mcfg_tailq_write_lock and do lookup
> for such entry and then read/update it as needed.
> It would help to avoid racing problem, plus you wouldn't need to
> allocate/lookup for memzone.
I don't quite like the idea of having a special entry with a different type
in an element list. Despite it is simpler for a locking perspective, it is
less obvious for the developper.
Also, I changed the way a zone is reserved to return the one that have the
less impact on next reservation, and I feel it is easier to implement with
the shared memory.
So, I just moved the init_shared_mem() inside the rte_mcfg_tailq_write_lock(),
it should do the job.
> > + if (params->size >= sizeof(struct rte_mbuf)) {
> > + rte_errno = EINVAL;
> > + goto fail;
> > + }
> > + if (!rte_is_power_of_2(params->align)) {
> > + rte_errno = EINVAL;
> > + goto fail;
> > + }
> > + if (params->flags != 0) {
> > + rte_errno = EINVAL;
> > + goto fail;
> > + }
> > +
> > + rte_mcfg_tailq_write_lock();
> > +
>
> I think it probably would be cleaner and easier to read/maintain, if you'll put actual
> code under lock protection into a separate function - as you did for __mbuf_dynfield_lookup().
Yes, I did that, it should be clearer now.
> > + mbuf_dynfield = __mbuf_dynfield_lookup(params->name);
> > + if (mbuf_dynfield != NULL) {
> > + if (mbuf_dynfield_cmp(params, &mbuf_dynfield->params) < 0) {
> > + rte_errno = EEXIST;
> > + goto fail_unlock;
> > + }
> > + offset = mbuf_dynfield->offset;
> > + goto out_unlock;
> > + }
> > +
> > + if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
> > + rte_errno = EPERM;
> > + goto fail_unlock;
> > + }
> > +
> > + for (offset = 0;
> > + offset < (int)sizeof(struct rte_mbuf);
> > + offset++) {
> > + if (check_offset(offset, params->size, params->align,
> > + params->flags) == 0)
> > + break;
> > + }
> > +
> > + if (offset == sizeof(struct rte_mbuf)) {
> > + rte_errno = ENOENT;
> > + goto fail_unlock;
> > + }
> > +
> > + mbuf_dynfield_list = RTE_TAILQ_CAST(
> > + mbuf_dynfield_tailq.head, mbuf_dynfield_list);
> > +
> > + te = rte_zmalloc("MBUF_DYNFIELD_TAILQ_ENTRY", sizeof(*te), 0);
> > + if (te == NULL)
> > + goto fail_unlock;
> > +
> > + mbuf_dynfield = rte_zmalloc("mbuf_dynfield", sizeof(*mbuf_dynfield), 0);
> > + if (mbuf_dynfield == NULL)
> > + goto fail_unlock;
> > +
> > + ret = strlcpy(mbuf_dynfield->params.name, params->name,
> > + sizeof(mbuf_dynfield->params.name));
> > + if (ret < 0 || ret >= (int)sizeof(mbuf_dynfield->params.name)) {
> > + rte_errno = ENAMETOOLONG;
> > + goto fail_unlock;
> > + }
> > + memcpy(&mbuf_dynfield->params, params, sizeof(mbuf_dynfield->params));
> > + mbuf_dynfield->offset = offset;
> > + te->data = mbuf_dynfield;
> > +
> > + TAILQ_INSERT_TAIL(mbuf_dynfield_list, te, next);
> > +
> > + for (i = offset; i < offset + params->size; i++)
> > + shm->free_space[i] = 0;
> > +
> > + RTE_LOG(DEBUG, MBUF, "Registered dynamic field %s (sz=%zu, al=%zu, fl=0x%x) -> %d\n",
> > + params->name, params->size, params->align, params->flags,
> > + offset);
> > +
> > +out_unlock:
> > + rte_mcfg_tailq_write_unlock();
> > +
> > + return offset;
> > +
> > +fail_unlock:
> > + rte_mcfg_tailq_write_unlock();
> > +fail:
> > + rte_free(mbuf_dynfield);
> > + rte_free(te);
> > + return -1;
> > +}
> > +
> > +/* assume tailq is locked */
> > +static struct mbuf_dynflag_elt *
> > +__mbuf_dynflag_lookup(const char *name)
> > +{
> > + struct mbuf_dynflag_list *mbuf_dynflag_list;
> > + struct mbuf_dynflag_elt *mbuf_dynflag;
> > + struct rte_tailq_entry *te;
> > +
> > + mbuf_dynflag_list = RTE_TAILQ_CAST(
> > + mbuf_dynflag_tailq.head, mbuf_dynflag_list);
> > +
> > + TAILQ_FOREACH(te, mbuf_dynflag_list, next) {
> > + mbuf_dynflag = (struct mbuf_dynflag_elt *)te->data;
> > + if (strncmp(name, mbuf_dynflag->params.name,
> > + RTE_MBUF_DYN_NAMESIZE) == 0)
> > + break;
> > + }
> > +
> > + if (te == NULL) {
> > + rte_errno = ENOENT;
> > + return NULL;
> > + }
> > +
> > + return mbuf_dynflag;
> > +}
> > +
> > +int
> > +rte_mbuf_dynflag_lookup(const char *name,
> > + struct rte_mbuf_dynflag *params)
> > +{
> > + struct mbuf_dynflag_elt *mbuf_dynflag;
> > +
> > + if (shm == NULL) {
> > + rte_errno = ENOENT;
> > + return -1;
> > + }
> > +
> > + rte_mcfg_tailq_read_lock();
> > + mbuf_dynflag = __mbuf_dynflag_lookup(name);
> > + rte_mcfg_tailq_read_unlock();
> > +
> > + if (mbuf_dynflag == NULL) {
> > + rte_errno = ENOENT;
> > + return -1;
> > + }
> > +
> > + if (params != NULL)
> > + memcpy(params, &mbuf_dynflag->params, sizeof(*params));
> > +
> > + return mbuf_dynflag->bitnum;
> > +}
> > +
> > +static int mbuf_dynflag_cmp(const struct rte_mbuf_dynflag *params1,
> > + const struct rte_mbuf_dynflag *params2)
> > +{
> > + if (strcmp(params1->name, params2->name))
> > + return -1;
> > + if (params1->flags != params2->flags)
> > + return -1;
> > + return 0;
> > +}
> > +
> > +int
> > +rte_mbuf_dynflag_register(const struct rte_mbuf_dynflag *params)
> > +{
> > + struct mbuf_dynflag_list *mbuf_dynflag_list;
> > + struct mbuf_dynflag_elt *mbuf_dynflag = NULL;
> > + struct rte_tailq_entry *te = NULL;
> > + int bitnum, ret;
> > +
> > + if (shm == NULL && init_shared_mem() < 0)
> > + goto fail;
> > +
> > + rte_mcfg_tailq_write_lock();
> > +
> > + mbuf_dynflag = __mbuf_dynflag_lookup(params->name);
> > + if (mbuf_dynflag != NULL) {
> > + if (mbuf_dynflag_cmp(params, &mbuf_dynflag->params) < 0) {
> > + rte_errno = EEXIST;
> > + goto fail_unlock;
> > + }
> > + bitnum = mbuf_dynflag->bitnum;
> > + goto out_unlock;
> > + }
> > +
> > + if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
> > + rte_errno = EPERM;
> > + goto fail_unlock;
> > + }
> > +
> > + if (shm->free_flags == 0) {
> > + rte_errno = ENOENT;
> > + goto fail_unlock;
> > + }
> > + bitnum = rte_bsf64(shm->free_flags);
> > +
> > + mbuf_dynflag_list = RTE_TAILQ_CAST(
> > + mbuf_dynflag_tailq.head, mbuf_dynflag_list);
> > +
> > + te = rte_zmalloc("MBUF_DYNFLAG_TAILQ_ENTRY", sizeof(*te), 0);
> > + if (te == NULL)
> > + goto fail_unlock;
> > +
> > + mbuf_dynflag = rte_zmalloc("mbuf_dynflag", sizeof(*mbuf_dynflag), 0);
> > + if (mbuf_dynflag == NULL)
> > + goto fail_unlock;
> > +
> > + ret = strlcpy(mbuf_dynflag->params.name, params->name,
> > + sizeof(mbuf_dynflag->params.name));
> > + if (ret < 0 || ret >= (int)sizeof(mbuf_dynflag->params.name)) {
> > + rte_errno = ENAMETOOLONG;
> > + goto fail_unlock;
> > + }
> > + mbuf_dynflag->bitnum = bitnum;
> > + te->data = mbuf_dynflag;
> > +
> > + TAILQ_INSERT_TAIL(mbuf_dynflag_list, te, next);
> > +
> > + shm->free_flags &= ~(1ULL << bitnum);
> > +
> > + RTE_LOG(DEBUG, MBUF, "Registered dynamic flag %s (fl=0x%x) -> %u\n",
> > + params->name, params->flags, bitnum);
> > +
> > +out_unlock:
> > + rte_mcfg_tailq_write_unlock();
> > +
> > + return bitnum;
> > +
> > +fail_unlock:
> > + rte_mcfg_tailq_write_unlock();
> > +fail:
> > + rte_free(mbuf_dynflag);
> > + rte_free(te);
> > + return -1;
> > +}
> > diff --git a/lib/librte_mbuf/rte_mbuf_dyn.h b/lib/librte_mbuf/rte_mbuf_dyn.h
> > new file mode 100644
> > index 000000000..6e2c81654
> > --- /dev/null
> > +++ b/lib/librte_mbuf/rte_mbuf_dyn.h
> > @@ -0,0 +1,163 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright 2019 6WIND S.A.
> > + */
> > +
> > +#ifndef _RTE_MBUF_DYN_H_
> > +#define _RTE_MBUF_DYN_H_
> > +
> > +/**
> > + * @file
> > + * RTE Mbuf 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 module addresses this issue, 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, stored
> > + * in mbuf->ol_flags.
> > + *
> > + * The typical use case is when a specific offload feature requires to
> > + * register a dedicated offload field in the mbuf structure, and adding
> > + * a static field or flag is not justified.
> > + *
> > + * Example of use:
> > + *
> > + * - A rte_mbuf_dynfield structure is defined, containing the parameters
> > + * of the dynamic field to be registered:
> > + * const struct rte_mbuf_dynfield rte_dynfield_my_feature = { ... };
> > + * - The application initializes the PMD, and asks for this feature
> > + * at port initialization by passing DEV_RX_OFFLOAD_MY_FEATURE in
> > + * rxconf. This will make the PMD to register the field by calling
> > + * rte_mbuf_dynfield_register(&rte_dynfield_my_feature). The PMD
> > + * stores the returned offset.
> > + * - The application that uses the offload feature also registers
> > + * the field to retrieve the same offset.
> > + * - When the PMD receives a packet, it can set the field:
> > + * *RTE_MBUF_DYNFIELD(m, offset, <type *>) = value;
> > + * - In the main loop, the application can retrieve the value with
> > + * the same macro.
> > + *
> > + * To avoid wasting space, the dynamic fields or flags must only be
> > + * reserved on demand, when an application asks for the related feature.
> > + *
> > + * The registration can be done at any moment, but it is not possible
> > + * to unregister fields or flags for now.
> > + *
> > + * A dynamic field can be reserved and used by an application only.
> > + * It can for instance be a packet mark.
> > + */
> > +
> > +#include <sys/types.h>
> > +/**
> > + * Maximum length of the dynamic field or flag string.
> > + */
> > +#define RTE_MBUF_DYN_NAMESIZE 64
> > +
> > +/**
> > + * Structure describing the parameters of a mbuf dynamic field.
> > + */
> > +struct rte_mbuf_dynfield {
> > + char name[RTE_MBUF_DYN_NAMESIZE]; /**< Name of the field. */
> > + size_t size; /**< The number of bytes to reserve. */
> > + size_t align; /**< The alignment constraint (power of 2). */
> > + unsigned int flags; /**< Reserved for future use, must be 0. */
> > +};
> > +
> > +/**
> > + * Structure describing the parameters of a mbuf dynamic flag.
> > + */
> > +struct rte_mbuf_dynflag {
> > + char name[RTE_MBUF_DYN_NAMESIZE]; /**< Name of the dynamic flag. */
> > + unsigned int flags; /**< Reserved for future use, must be 0. */
> > +};
> > +
> > +/**
> > + * Register space for a dynamic field in the mbuf structure.
> > + *
> > + * If the field is already registered (same name and parameters), its
> > + * offset is returned.
> > + *
> > + * @param params
> > + * A structure containing the requested parameters (name, size,
> > + * alignment constraint and flags).
> > + * @return
> > + * The offset in the mbuf structure, or -1 on error.
> > + * Possible values for rte_errno:
> > + * - EINVAL: invalid parameters (size, align, or flags).
> > + * - EEXIST: this name is already register with different parameters.
> > + * - EPERM: called from a secondary process.
> > + * - ENOENT: not enough room in mbuf.
> > + * - ENOMEM: allocation failure.
> > + * - ENAMETOOLONG: name does not ends with \0.
> > + */
> > +__rte_experimental
> > +int rte_mbuf_dynfield_register(const struct rte_mbuf_dynfield *params);
> > +
> > +/**
> > + * Lookup for a registered dynamic mbuf field.
> > + *
> > + * @param name
> > + * A string identifying the dynamic field.
> > + * @param params
> > + * If not NULL, and if the lookup is successful, the structure is
> > + * filled with the parameters of the dynamic field.
> > + * @return
> > + * The offset of this field in the mbuf structure, or -1 on error.
> > + * Possible values for rte_errno:
> > + * - ENOENT: no dynamic field matches this name.
> > + */
> > +__rte_experimental
> > +int rte_mbuf_dynfield_lookup(const char *name,
> > + struct rte_mbuf_dynfield *params);
> > +
> > +/**
> > + * Register a dynamic flag in the mbuf structure.
> > + *
> > + * If the flag is already registered (same name and parameters), its
> > + * offset is returned.
> > + *
> > + * @param params
> > + * A structure containing the requested parameters of the dynamic
> > + * flag (name and options).
> > + * @return
> > + * The number of the reserved bit, or -1 on error.
> > + * Possible values for rte_errno:
> > + * - EINVAL: invalid parameters (size, align, or flags).
> > + * - EEXIST: this name is already register with different parameters.
> > + * - EPERM: called from a secondary process.
> > + * - ENOENT: no more flag available.
> > + * - ENOMEM: allocation failure.
> > + * - ENAMETOOLONG: name is longer than RTE_MBUF_DYN_NAMESIZE - 1.
> > + */
> > +__rte_experimental
> > +int rte_mbuf_dynflag_register(const struct rte_mbuf_dynflag *params);
> > +
> > +/**
> > + * Lookup for a registered dynamic mbuf flag.
> > + *
> > + * @param name
> > + * A string identifying the dynamic flag.
> > + * @param params
> > + * If not NULL, and if the lookup is successful, the structure is
> > + * filled with the parameters of the dynamic flag.
> > + * @return
> > + * The offset of this flag in the mbuf structure, or -1 on error.
> > + * Possible values for rte_errno:
> > + * - ENOENT: no dynamic flag matches this name.
> > + */
> > +__rte_experimental
> > +int rte_mbuf_dynflag_lookup(const char *name,
> > + struct rte_mbuf_dynflag *params);
> > +
> > +/**
> > + * Helper macro to access to a dynamic field.
> > + */
> > +#define RTE_MBUF_DYNFIELD(m, offset, type) ((type)((uintptr_t)(m) + (offset)))
> > +
> > +#endif
> > diff --git a/lib/librte_mbuf/rte_mbuf_version.map b/lib/librte_mbuf/rte_mbuf_version.map
> > index 2662a37bf..a98310570 100644
> > --- a/lib/librte_mbuf/rte_mbuf_version.map
> > +++ b/lib/librte_mbuf/rte_mbuf_version.map
> > @@ -50,4 +50,8 @@ EXPERIMENTAL {
> > global:
> >
> > rte_mbuf_check;
> > + rte_mbuf_dynfield_lookup;
> > + rte_mbuf_dynfield_register;
> > + rte_mbuf_dynflag_lookup;
> > + rte_mbuf_dynflag_register;
> > } DPDK_18.08;
> > --
> > 2.20.1
>
I will send a v2 shortly, thanks
Olivier
Hi Olivier,
> > > 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.
> >
> > Looks ok to me in general.
> > Some comments/suggestions inline.
> > Konstantin
> >
> > >
> > > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> > > Acked-by: Thomas Monjalon <thomas@monjalon.net>
> > > ---
> > >
> > > 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 | 114 ++++++-
> > > 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 | 25 +-
> > > lib/librte_mbuf/rte_mbuf_dyn.c | 408 +++++++++++++++++++++++++
> > > lib/librte_mbuf/rte_mbuf_dyn.h | 163 ++++++++++
> > > lib/librte_mbuf/rte_mbuf_version.map | 4 +
> > > 8 files changed, 724 insertions(+), 5 deletions(-)
> > > create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.c
> > > create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.h
> > >
> > > --- a/lib/librte_mbuf/rte_mbuf.h
> > > +++ b/lib/librte_mbuf/rte_mbuf.h
> > > @@ -198,9 +198,12 @@ extern "C" {
> > > #define PKT_RX_OUTER_L4_CKSUM_GOOD (1ULL << 22)
> > > #define PKT_RX_OUTER_L4_CKSUM_INVALID ((1ULL << 21) | (1ULL << 22))
> > >
> > > -/* add new RX flags here */
> > > +/* add new RX flags here, don't forget to update PKT_FIRST_FREE */
> > >
> > > -/* add new TX flags here */
> > > +#define PKT_FIRST_FREE (1ULL << 23)
> > > +#define PKT_LAST_FREE (1ULL << 39)
> > > +
> > > +/* add new TX flags here, don't forget to update PKT_LAST_FREE */
> > >
> > > /**
> > > * Indicate that the metadata field in the mbuf is in use.
> > > @@ -738,6 +741,8 @@ struct rte_mbuf {
> > > */
> > > struct rte_mbuf_ext_shared_info *shinfo;
> > >
> > > + uint64_t dynfield1; /**< Reserved for dynamic fields. */
> > > + uint64_t dynfield2; /**< Reserved for dynamic fields. */
> >
> > Wonder why just not one field:
> > union {
> > uint8_t u8[16];
> > ...
> > uint64_t u64[2];
> > } dyn_field1;
> > ?
> > Probably would be a bit handy, to refer, register, etc. no?
>
> I didn't find any place where we need an access through u8, so I
> just changed it into uint64_t dynfield1[2].
My thought was - if you'll have all dynamic stuff as one field (uint64_t dyn_field[2]),
then you woulnd't need any cycles at register() at all.
But up to you.
>
>
> >
> > > } __rte_cache_aligned;
> > >
> > > /**
> > > @@ -1684,6 +1689,21 @@ rte_pktmbuf_attach_extbuf(struct rte_mbuf *m, void *buf_addr,
> > > */
> > > #define rte_pktmbuf_detach_extbuf(m) rte_pktmbuf_detach(m)
> > >
> > > +/**
> > > + * Copy dynamic fields from m_src to m_dst.
> > > + *
> > > + * @param m_dst
> > > + * The destination mbuf.
> > > + * @param m_src
> > > + * The source mbuf.
> > > + */
> > > +static inline void
> > > +rte_mbuf_dynfield_copy(struct rte_mbuf *m_dst, const struct rte_mbuf *m_src)
> > > +{
> > > + m_dst->dynfield1 = m_src->dynfield1;
> > > + m_dst->dynfield2 = m_src->dynfield2;
> > > +}
> > > +
> > > /**
> > > * Attach packet mbuf to another packet mbuf.
> > > *
> > > @@ -1732,6 +1752,7 @@ static inline void rte_pktmbuf_attach(struct rte_mbuf *mi, struct rte_mbuf *m)
> > > mi->vlan_tci_outer = m->vlan_tci_outer;
> > > mi->tx_offload = m->tx_offload;
> > > mi->hash = m->hash;
> > > + rte_mbuf_dynfield_copy(mi, m);
> > >
> > > mi->next = NULL;
> > > mi->pkt_len = mi->data_len;
> > > diff --git a/lib/librte_mbuf/rte_mbuf_dyn.c b/lib/librte_mbuf/rte_mbuf_dyn.c
> > > new file mode 100644
> > > index 000000000..13b8742d0
> > > --- /dev/null
> > > +++ b/lib/librte_mbuf/rte_mbuf_dyn.c
> > > @@ -0,0 +1,408 @@
> > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > + * Copyright 2019 6WIND S.A.
> > > + */
> > > +
> > > +#include <sys/queue.h>
> > > +
> > > +#include <rte_common.h>
> > > +#include <rte_eal.h>
> > > +#include <rte_eal_memconfig.h>
> > > +#include <rte_tailq.h>
> > > +#include <rte_errno.h>
> > > +#include <rte_malloc.h>
> > > +#include <rte_string_fns.h>
> > > +#include <rte_mbuf.h>
> > > +#include <rte_mbuf_dyn.h>
> > > +
> > > +#define RTE_MBUF_DYN_MZNAME "rte_mbuf_dyn"
> > > +
> > > +struct mbuf_dynfield_elt {
> > > + TAILQ_ENTRY(mbuf_dynfield_elt) next;
> > > + struct rte_mbuf_dynfield params;
> > > + int offset;
> >
> > Why not 'size_t offset', to avoid any explicit conversions, etc?
>
> Fixed
>
>
> > > +};
> > > +TAILQ_HEAD(mbuf_dynfield_list, rte_tailq_entry);
> > > +
> > > +static struct rte_tailq_elem mbuf_dynfield_tailq = {
> > > + .name = "RTE_MBUF_DYNFIELD",
> > > +};
> > > +EAL_REGISTER_TAILQ(mbuf_dynfield_tailq);
> > > +
> > > +struct mbuf_dynflag_elt {
> > > + TAILQ_ENTRY(mbuf_dynflag_elt) next;
> > > + struct rte_mbuf_dynflag params;
> > > + int bitnum;
> > > +};
> > > +TAILQ_HEAD(mbuf_dynflag_list, rte_tailq_entry);
> > > +
> > > +static struct rte_tailq_elem mbuf_dynflag_tailq = {
> > > + .name = "RTE_MBUF_DYNFLAG",
> > > +};
> > > +EAL_REGISTER_TAILQ(mbuf_dynflag_tailq);
> > > +
> > > +struct mbuf_dyn_shm {
> > > + /** For each mbuf byte, free_space[i] == 1 if space is free. */
> > > + uint8_t free_space[sizeof(struct rte_mbuf)];
> > > + /** Bitfield of available flags. */
> > > + uint64_t free_flags;
> > > +};
> > > +static struct mbuf_dyn_shm *shm;
> > > +
> > > +/* allocate and initialize the shared memory */
> > > +static int
> > > +init_shared_mem(void)
> > > +{
> > > + const struct rte_memzone *mz;
> > > + uint64_t mask;
> > > +
> > > + if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
> > > + mz = rte_memzone_reserve_aligned(RTE_MBUF_DYN_MZNAME,
> > > + sizeof(struct mbuf_dyn_shm),
> > > + SOCKET_ID_ANY, 0,
> > > + RTE_CACHE_LINE_SIZE);
> > > + } else {
> > > + mz = rte_memzone_lookup(RTE_MBUF_DYN_MZNAME);
> > > + }
> > > + if (mz == NULL)
> > > + return -1;
> > > +
> > > + shm = mz->addr;
> > > +
> > > +#define mark_free(field) \
> > > + memset(&shm->free_space[offsetof(struct rte_mbuf, field)], \
> > > + 0xff, sizeof(((struct rte_mbuf *)0)->field))
> >
> > I think you can avoid defining/unedifying macros here by something like that:
> >
> > static const struct {
> > size_t offset;
> > size_t size;
> > } dyn_syms[] = {
> > [0] = {.offset = offsetof(struct rte_mbuf, dynfield1), sizeof((struct rte_mbuf *)0)->dynfield1),
> > [1] = {.offset = offsetof(struct rte_mbuf, dynfield2), sizeof((struct rte_mbuf *)0)->dynfield2),
> > };
> > ...
> >
> > for (i = 0; i != RTE_DIM(dyn_syms); i++)
> > memset(shm->free_space + dym_syms[i].offset, UINT8_MAX, dym_syms[i].size);
> >
>
> I tried it, but the following lines are too long
> [0] = {offsetof(struct rte_mbuf, dynfield1), sizeof((struct rte_mbuf *)0)->dynfield1),
> [1] = {offsetof(struct rte_mbuf, dynfield2), sizeof((struct rte_mbuf *)0)->dynfield2),
> To make them shorter, we can use a macro... but... wait :)
Guess what, you can put offset ans size on different lines :)
[0] = {
.offset = offsetof(struct rte_mbuf, dynfield1),
.size= sizeof((struct rte_mbuf *)0)->dynfield1),
},
....
>
> > > +
> > > + if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
> > > + /* init free_space, keep it sync'd with
> > > + * rte_mbuf_dynfield_copy().
> > > + */
> > > + memset(shm, 0, sizeof(*shm));
> > > + mark_free(dynfield1);
> > > + mark_free(dynfield2);
> > > +
> > > + /* init free_flags */
> > > + for (mask = PKT_FIRST_FREE; mask <= PKT_LAST_FREE; mask <<= 1)
> > > + shm->free_flags |= mask;
> > > + }
> > > +#undef mark_free
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +/* check if this offset can be used */
> > > +static int
> > > +check_offset(size_t offset, size_t size, size_t align, unsigned int flags)
> > > +{
> > > + size_t i;
> > > +
> > > + (void)flags;
> >
> >
> > We have RTE_SET_USED() for such cases...
> > Though as it is an internal function probably better not to introduce
> > unused parameters at all.
>
> I removed the flag parameter as you suggested.
>
>
> > > +
> > > + if ((offset & (align - 1)) != 0)
> > > + return -1;
> > > + if (offset + size > sizeof(struct rte_mbuf))
> > > + return -1;
> > > +
> > > + for (i = 0; i < size; i++) {
> > > + if (!shm->free_space[i + offset])
> > > + return -1;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +/* assume tailq is locked */
> > > +static struct mbuf_dynfield_elt *
> > > +__mbuf_dynfield_lookup(const char *name)
> > > +{
> > > + struct mbuf_dynfield_list *mbuf_dynfield_list;
> > > + struct mbuf_dynfield_elt *mbuf_dynfield;
> > > + struct rte_tailq_entry *te;
> > > +
> > > + mbuf_dynfield_list = RTE_TAILQ_CAST(
> > > + mbuf_dynfield_tailq.head, mbuf_dynfield_list);
> > > +
> > > + TAILQ_FOREACH(te, mbuf_dynfield_list, next) {
> > > + mbuf_dynfield = (struct mbuf_dynfield_elt *)te->data;
> > > + if (strcmp(name, mbuf_dynfield->params.name) == 0)
> > > + break;
> > > + }
> > > +
> > > + if (te == NULL) {
> > > + rte_errno = ENOENT;
> > > + return NULL;
> > > + }
> > > +
> > > + return mbuf_dynfield;
> > > +}
> > > +
> > > +int
> > > +rte_mbuf_dynfield_lookup(const char *name, struct rte_mbuf_dynfield *params)
> > > +{
> > > + struct mbuf_dynfield_elt *mbuf_dynfield;
> > > +
> > > + if (shm == NULL) {
> > > + rte_errno = ENOENT;
> > > + return -1;
> > > + }
> > > +
> > > + rte_mcfg_tailq_read_lock();
> > > + mbuf_dynfield = __mbuf_dynfield_lookup(name);
> > > + rte_mcfg_tailq_read_unlock();
> > > +
> > > + if (mbuf_dynfield == NULL) {
> > > + rte_errno = ENOENT;
> > > + return -1;
> > > + }
> > > +
> > > + if (params != NULL)
> > > + memcpy(params, &mbuf_dynfield->params, sizeof(*params));
> > > +
> > > + return mbuf_dynfield->offset;
> > > +}
> > > +
> > > +static int mbuf_dynfield_cmp(const struct rte_mbuf_dynfield *params1,
> > > + const struct rte_mbuf_dynfield *params2)
> > > +{
> > > + if (strcmp(params1->name, params2->name))
> > > + return -1;
> > > + if (params1->size != params2->size)
> > > + return -1;
> > > + if (params1->align != params2->align)
> > > + return -1;
> > > + if (params1->flags != params2->flags)
> > > + return -1;
> > > + return 0;
> > > +}
> > > +
> > > +int
> > > +rte_mbuf_dynfield_register(const struct rte_mbuf_dynfield *params)
> >
> > What I meant at user-space - if we can also have another function that would allow
> > user to specify required offset for dynfield explicitly, then user can define it as constant
> > value and let compiler do optimization work and hopefully generate faster code to access
> > this field.
> > Something like that:
> >
> > int rte_mbuf_dynfiled_register_offset(const struct rte_mbuf_dynfield *params, size_t offset);
> >
> > #define RTE_MBUF_DYNFIELD_OFFSET(fld, off) (offsetof(struct rte_mbuf, fld) + (off))
> >
> > And then somewhere in user code:
> >
> > /* to let say reserve first 4B in dynfield1*/
> > #define MBUF_DYNFIELD_A RTE_MBUF_DYNFIELD_OFFSET(dynfiled1, 0)
> > ...
> > params.name = RTE_STR(MBUF_DYNFIELD_A);
> > params.size = sizeof(uint32_t);
> > params.align = sizeof(uint32_t);
> > ret = rte_mbuf_dynfiled_register_offset(¶ms, MBUF_DYNFIELD_A);
> > if (ret != MBUF_DYNFIELD_A) {
> > /* handle it somehow, probably just terminate gracefully... */
> > }
> > ...
> >
> > /* to let say reserve last 2B in dynfield2*/
> > #define MBUF_DYNFIELD_B RTE_MBUF_DYNFIELD_OFFSET(dynfiled2, 6)
> > ...
> > params.name = RTE_STR(MBUF_DYNFIELD_B);
> > params.size = sizeof(uint16_t);
> > params.align = sizeof(uint16_t);
> > ret = rte_mbuf_dynfiled_register_offset(¶ms, MBUF_DYNFIELD_B);
> >
> > After that user can use constant offsets MBUF_DYNFIELD_A/ MBUF_DYNFIELD_B
> > to access these fields.
> > Same thoughts for DYNFLAG.
>
> I added the feature in v2.
>
>
> > > + struct mbuf_dynfield_list *mbuf_dynfield_list;
> > > + struct mbuf_dynfield_elt *mbuf_dynfield = NULL;
> > > + struct rte_tailq_entry *te = NULL;
> > > + int offset, ret;
> >
> > size_t offset
> > to avoid explicit conversions, etc.?
> >
>
> Fixed.
>
>
> > > + size_t i;
> > > +
> > > + if (shm == NULL && init_shared_mem() < 0)
> > > + goto fail;
> >
> > As I understand, here you allocate/initialize your shm without any lock protection,
> > though later you protect it via rte_mcfg_tailq_write_lock().
> > That seems a bit flakey to me.
> > Why not to store information about free dynfield bytes inside mbuf_dynfield_tailq?
> > Let say at init() create and add an entry into that list with some reserved name.
> > Then at register - grab mcfg_tailq_write_lock and do lookup
> > for such entry and then read/update it as needed.
> > It would help to avoid racing problem, plus you wouldn't need to
> > allocate/lookup for memzone.
>
> I don't quite like the idea of having a special entry with a different type
> in an element list. Despite it is simpler for a locking perspective, it is
> less obvious for the developper.
>
> Also, I changed the way a zone is reserved to return the one that have the
> less impact on next reservation, and I feel it is easier to implement with
> the shared memory.
>
> So, I just moved the init_shared_mem() inside the rte_mcfg_tailq_write_lock(),
> it should do the job.
Yep, that should work too, I think.
>
>
> > > + if (params->size >= sizeof(struct rte_mbuf)) {
> > > + rte_errno = EINVAL;
> > > + goto fail;
> > > + }
> > > + if (!rte_is_power_of_2(params->align)) {
> > > + rte_errno = EINVAL;
> > > + goto fail;
> > > + }
> > > + if (params->flags != 0) {
> > > + rte_errno = EINVAL;
> > > + goto fail;
> > > + }
> > > +
> > > + rte_mcfg_tailq_write_lock();
> > > +
> >
> > I think it probably would be cleaner and easier to read/maintain, if you'll put actual
> > code under lock protection into a separate function - as you did for __mbuf_dynfield_lookup().
>
> Yes, I did that, it should be clearer now.
>
>
Hi Konstantin,
On Thu, Oct 17, 2019 at 11:58:52AM +0000, Ananyev, Konstantin wrote:
>
> Hi Olivier,
>
> > > > 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.
> > >
> > > Looks ok to me in general.
> > > Some comments/suggestions inline.
> > > Konstantin
> > >
> > > >
> > > > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> > > > Acked-by: Thomas Monjalon <thomas@monjalon.net>
> > > > ---
> > > >
> > > > 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 | 114 ++++++-
> > > > 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 | 25 +-
> > > > lib/librte_mbuf/rte_mbuf_dyn.c | 408 +++++++++++++++++++++++++
> > > > lib/librte_mbuf/rte_mbuf_dyn.h | 163 ++++++++++
> > > > lib/librte_mbuf/rte_mbuf_version.map | 4 +
> > > > 8 files changed, 724 insertions(+), 5 deletions(-)
> > > > create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.c
> > > > create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.h
> > > >
> > > > --- a/lib/librte_mbuf/rte_mbuf.h
> > > > +++ b/lib/librte_mbuf/rte_mbuf.h
> > > > @@ -198,9 +198,12 @@ extern "C" {
> > > > #define PKT_RX_OUTER_L4_CKSUM_GOOD (1ULL << 22)
> > > > #define PKT_RX_OUTER_L4_CKSUM_INVALID ((1ULL << 21) | (1ULL << 22))
> > > >
> > > > -/* add new RX flags here */
> > > > +/* add new RX flags here, don't forget to update PKT_FIRST_FREE */
> > > >
> > > > -/* add new TX flags here */
> > > > +#define PKT_FIRST_FREE (1ULL << 23)
> > > > +#define PKT_LAST_FREE (1ULL << 39)
> > > > +
> > > > +/* add new TX flags here, don't forget to update PKT_LAST_FREE */
> > > >
> > > > /**
> > > > * Indicate that the metadata field in the mbuf is in use.
> > > > @@ -738,6 +741,8 @@ struct rte_mbuf {
> > > > */
> > > > struct rte_mbuf_ext_shared_info *shinfo;
> > > >
> > > > + uint64_t dynfield1; /**< Reserved for dynamic fields. */
> > > > + uint64_t dynfield2; /**< Reserved for dynamic fields. */
> > >
> > > Wonder why just not one field:
> > > union {
> > > uint8_t u8[16];
> > > ...
> > > uint64_t u64[2];
> > > } dyn_field1;
> > > ?
> > > Probably would be a bit handy, to refer, register, etc. no?
> >
> > I didn't find any place where we need an access through u8, so I
> > just changed it into uint64_t dynfield1[2].
>
> My thought was - if you'll have all dynamic stuff as one field (uint64_t dyn_field[2]),
> then you woulnd't need any cycles at register() at all.
> But up to you.
I changed it.
> >
> > >
> > > > } __rte_cache_aligned;
> > > >
> > > > /**
> > > > @@ -1684,6 +1689,21 @@ rte_pktmbuf_attach_extbuf(struct rte_mbuf *m, void *buf_addr,
> > > > */
> > > > #define rte_pktmbuf_detach_extbuf(m) rte_pktmbuf_detach(m)
> > > >
> > > > +/**
> > > > + * Copy dynamic fields from m_src to m_dst.
> > > > + *
> > > > + * @param m_dst
> > > > + * The destination mbuf.
> > > > + * @param m_src
> > > > + * The source mbuf.
> > > > + */
> > > > +static inline void
> > > > +rte_mbuf_dynfield_copy(struct rte_mbuf *m_dst, const struct rte_mbuf *m_src)
> > > > +{
> > > > + m_dst->dynfield1 = m_src->dynfield1;
> > > > + m_dst->dynfield2 = m_src->dynfield2;
> > > > +}
> > > > +
> > > > /**
> > > > * Attach packet mbuf to another packet mbuf.
> > > > *
> > > > @@ -1732,6 +1752,7 @@ static inline void rte_pktmbuf_attach(struct rte_mbuf *mi, struct rte_mbuf *m)
> > > > mi->vlan_tci_outer = m->vlan_tci_outer;
> > > > mi->tx_offload = m->tx_offload;
> > > > mi->hash = m->hash;
> > > > + rte_mbuf_dynfield_copy(mi, m);
> > > >
> > > > mi->next = NULL;
> > > > mi->pkt_len = mi->data_len;
> > > > diff --git a/lib/librte_mbuf/rte_mbuf_dyn.c b/lib/librte_mbuf/rte_mbuf_dyn.c
> > > > new file mode 100644
> > > > index 000000000..13b8742d0
> > > > --- /dev/null
> > > > +++ b/lib/librte_mbuf/rte_mbuf_dyn.c
> > > > @@ -0,0 +1,408 @@
> > > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > > + * Copyright 2019 6WIND S.A.
> > > > + */
> > > > +
> > > > +#include <sys/queue.h>
> > > > +
> > > > +#include <rte_common.h>
> > > > +#include <rte_eal.h>
> > > > +#include <rte_eal_memconfig.h>
> > > > +#include <rte_tailq.h>
> > > > +#include <rte_errno.h>
> > > > +#include <rte_malloc.h>
> > > > +#include <rte_string_fns.h>
> > > > +#include <rte_mbuf.h>
> > > > +#include <rte_mbuf_dyn.h>
> > > > +
> > > > +#define RTE_MBUF_DYN_MZNAME "rte_mbuf_dyn"
> > > > +
> > > > +struct mbuf_dynfield_elt {
> > > > + TAILQ_ENTRY(mbuf_dynfield_elt) next;
> > > > + struct rte_mbuf_dynfield params;
> > > > + int offset;
> > >
> > > Why not 'size_t offset', to avoid any explicit conversions, etc?
> >
> > Fixed
> >
> >
> > > > +};
> > > > +TAILQ_HEAD(mbuf_dynfield_list, rte_tailq_entry);
> > > > +
> > > > +static struct rte_tailq_elem mbuf_dynfield_tailq = {
> > > > + .name = "RTE_MBUF_DYNFIELD",
> > > > +};
> > > > +EAL_REGISTER_TAILQ(mbuf_dynfield_tailq);
> > > > +
> > > > +struct mbuf_dynflag_elt {
> > > > + TAILQ_ENTRY(mbuf_dynflag_elt) next;
> > > > + struct rte_mbuf_dynflag params;
> > > > + int bitnum;
> > > > +};
> > > > +TAILQ_HEAD(mbuf_dynflag_list, rte_tailq_entry);
> > > > +
> > > > +static struct rte_tailq_elem mbuf_dynflag_tailq = {
> > > > + .name = "RTE_MBUF_DYNFLAG",
> > > > +};
> > > > +EAL_REGISTER_TAILQ(mbuf_dynflag_tailq);
> > > > +
> > > > +struct mbuf_dyn_shm {
> > > > + /** For each mbuf byte, free_space[i] == 1 if space is free. */
> > > > + uint8_t free_space[sizeof(struct rte_mbuf)];
> > > > + /** Bitfield of available flags. */
> > > > + uint64_t free_flags;
> > > > +};
> > > > +static struct mbuf_dyn_shm *shm;
> > > > +
> > > > +/* allocate and initialize the shared memory */
> > > > +static int
> > > > +init_shared_mem(void)
> > > > +{
> > > > + const struct rte_memzone *mz;
> > > > + uint64_t mask;
> > > > +
> > > > + if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
> > > > + mz = rte_memzone_reserve_aligned(RTE_MBUF_DYN_MZNAME,
> > > > + sizeof(struct mbuf_dyn_shm),
> > > > + SOCKET_ID_ANY, 0,
> > > > + RTE_CACHE_LINE_SIZE);
> > > > + } else {
> > > > + mz = rte_memzone_lookup(RTE_MBUF_DYN_MZNAME);
> > > > + }
> > > > + if (mz == NULL)
> > > > + return -1;
> > > > +
> > > > + shm = mz->addr;
> > > > +
> > > > +#define mark_free(field) \
> > > > + memset(&shm->free_space[offsetof(struct rte_mbuf, field)], \
> > > > + 0xff, sizeof(((struct rte_mbuf *)0)->field))
> > >
> > > I think you can avoid defining/unedifying macros here by something like that:
> > >
> > > static const struct {
> > > size_t offset;
> > > size_t size;
> > > } dyn_syms[] = {
> > > [0] = {.offset = offsetof(struct rte_mbuf, dynfield1), sizeof((struct rte_mbuf *)0)->dynfield1),
> > > [1] = {.offset = offsetof(struct rte_mbuf, dynfield2), sizeof((struct rte_mbuf *)0)->dynfield2),
> > > };
> > > ...
> > >
> > > for (i = 0; i != RTE_DIM(dyn_syms); i++)
> > > memset(shm->free_space + dym_syms[i].offset, UINT8_MAX, dym_syms[i].size);
> > >
> >
> > I tried it, but the following lines are too long
> > [0] = {offsetof(struct rte_mbuf, dynfield1), sizeof((struct rte_mbuf *)0)->dynfield1),
> > [1] = {offsetof(struct rte_mbuf, dynfield2), sizeof((struct rte_mbuf *)0)->dynfield2),
> > To make them shorter, we can use a macro... but... wait :)
>
> Guess what, you can put offset ans size on different lines :)
> [0] = {
> .offset = offsetof(struct rte_mbuf, dynfield1),
> .size= sizeof((struct rte_mbuf *)0)->dynfield1),
> },
Yes, but honnestly, I'm not sure that it will be more readable than
the macro, knowing that we could add fields in the future.
> ....
>
> >
> > > > +
> > > > + if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
> > > > + /* init free_space, keep it sync'd with
> > > > + * rte_mbuf_dynfield_copy().
> > > > + */
> > > > + memset(shm, 0, sizeof(*shm));
> > > > + mark_free(dynfield1);
> > > > + mark_free(dynfield2);
> > > > +
> > > > + /* init free_flags */
> > > > + for (mask = PKT_FIRST_FREE; mask <= PKT_LAST_FREE; mask <<= 1)
> > > > + shm->free_flags |= mask;
> > > > + }
> > > > +#undef mark_free
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +/* check if this offset can be used */
> > > > +static int
> > > > +check_offset(size_t offset, size_t size, size_t align, unsigned int flags)
> > > > +{
> > > > + size_t i;
> > > > +
> > > > + (void)flags;
> > >
> > >
> > > We have RTE_SET_USED() for such cases...
> > > Though as it is an internal function probably better not to introduce
> > > unused parameters at all.
> >
> > I removed the flag parameter as you suggested.
> >
> >
> > > > +
> > > > + if ((offset & (align - 1)) != 0)
> > > > + return -1;
> > > > + if (offset + size > sizeof(struct rte_mbuf))
> > > > + return -1;
> > > > +
> > > > + for (i = 0; i < size; i++) {
> > > > + if (!shm->free_space[i + offset])
> > > > + return -1;
> > > > + }
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +/* assume tailq is locked */
> > > > +static struct mbuf_dynfield_elt *
> > > > +__mbuf_dynfield_lookup(const char *name)
> > > > +{
> > > > + struct mbuf_dynfield_list *mbuf_dynfield_list;
> > > > + struct mbuf_dynfield_elt *mbuf_dynfield;
> > > > + struct rte_tailq_entry *te;
> > > > +
> > > > + mbuf_dynfield_list = RTE_TAILQ_CAST(
> > > > + mbuf_dynfield_tailq.head, mbuf_dynfield_list);
> > > > +
> > > > + TAILQ_FOREACH(te, mbuf_dynfield_list, next) {
> > > > + mbuf_dynfield = (struct mbuf_dynfield_elt *)te->data;
> > > > + if (strcmp(name, mbuf_dynfield->params.name) == 0)
> > > > + break;
> > > > + }
> > > > +
> > > > + if (te == NULL) {
> > > > + rte_errno = ENOENT;
> > > > + return NULL;
> > > > + }
> > > > +
> > > > + return mbuf_dynfield;
> > > > +}
> > > > +
> > > > +int
> > > > +rte_mbuf_dynfield_lookup(const char *name, struct rte_mbuf_dynfield *params)
> > > > +{
> > > > + struct mbuf_dynfield_elt *mbuf_dynfield;
> > > > +
> > > > + if (shm == NULL) {
> > > > + rte_errno = ENOENT;
> > > > + return -1;
> > > > + }
> > > > +
> > > > + rte_mcfg_tailq_read_lock();
> > > > + mbuf_dynfield = __mbuf_dynfield_lookup(name);
> > > > + rte_mcfg_tailq_read_unlock();
> > > > +
> > > > + if (mbuf_dynfield == NULL) {
> > > > + rte_errno = ENOENT;
> > > > + return -1;
> > > > + }
> > > > +
> > > > + if (params != NULL)
> > > > + memcpy(params, &mbuf_dynfield->params, sizeof(*params));
> > > > +
> > > > + return mbuf_dynfield->offset;
> > > > +}
> > > > +
> > > > +static int mbuf_dynfield_cmp(const struct rte_mbuf_dynfield *params1,
> > > > + const struct rte_mbuf_dynfield *params2)
> > > > +{
> > > > + if (strcmp(params1->name, params2->name))
> > > > + return -1;
> > > > + if (params1->size != params2->size)
> > > > + return -1;
> > > > + if (params1->align != params2->align)
> > > > + return -1;
> > > > + if (params1->flags != params2->flags)
> > > > + return -1;
> > > > + return 0;
> > > > +}
> > > > +
> > > > +int
> > > > +rte_mbuf_dynfield_register(const struct rte_mbuf_dynfield *params)
> > >
> > > What I meant at user-space - if we can also have another function that would allow
> > > user to specify required offset for dynfield explicitly, then user can define it as constant
> > > value and let compiler do optimization work and hopefully generate faster code to access
> > > this field.
> > > Something like that:
> > >
> > > int rte_mbuf_dynfiled_register_offset(const struct rte_mbuf_dynfield *params, size_t offset);
> > >
> > > #define RTE_MBUF_DYNFIELD_OFFSET(fld, off) (offsetof(struct rte_mbuf, fld) + (off))
> > >
> > > And then somewhere in user code:
> > >
> > > /* to let say reserve first 4B in dynfield1*/
> > > #define MBUF_DYNFIELD_A RTE_MBUF_DYNFIELD_OFFSET(dynfiled1, 0)
> > > ...
> > > params.name = RTE_STR(MBUF_DYNFIELD_A);
> > > params.size = sizeof(uint32_t);
> > > params.align = sizeof(uint32_t);
> > > ret = rte_mbuf_dynfiled_register_offset(¶ms, MBUF_DYNFIELD_A);
> > > if (ret != MBUF_DYNFIELD_A) {
> > > /* handle it somehow, probably just terminate gracefully... */
> > > }
> > > ...
> > >
> > > /* to let say reserve last 2B in dynfield2*/
> > > #define MBUF_DYNFIELD_B RTE_MBUF_DYNFIELD_OFFSET(dynfiled2, 6)
> > > ...
> > > params.name = RTE_STR(MBUF_DYNFIELD_B);
> > > params.size = sizeof(uint16_t);
> > > params.align = sizeof(uint16_t);
> > > ret = rte_mbuf_dynfiled_register_offset(¶ms, MBUF_DYNFIELD_B);
> > >
> > > After that user can use constant offsets MBUF_DYNFIELD_A/ MBUF_DYNFIELD_B
> > > to access these fields.
> > > Same thoughts for DYNFLAG.
> >
> > I added the feature in v2.
> >
> >
> > > > + struct mbuf_dynfield_list *mbuf_dynfield_list;
> > > > + struct mbuf_dynfield_elt *mbuf_dynfield = NULL;
> > > > + struct rte_tailq_entry *te = NULL;
> > > > + int offset, ret;
> > >
> > > size_t offset
> > > to avoid explicit conversions, etc.?
> > >
> >
> > Fixed.
> >
> >
> > > > + size_t i;
> > > > +
> > > > + if (shm == NULL && init_shared_mem() < 0)
> > > > + goto fail;
> > >
> > > As I understand, here you allocate/initialize your shm without any lock protection,
> > > though later you protect it via rte_mcfg_tailq_write_lock().
> > > That seems a bit flakey to me.
> > > Why not to store information about free dynfield bytes inside mbuf_dynfield_tailq?
> > > Let say at init() create and add an entry into that list with some reserved name.
> > > Then at register - grab mcfg_tailq_write_lock and do lookup
> > > for such entry and then read/update it as needed.
> > > It would help to avoid racing problem, plus you wouldn't need to
> > > allocate/lookup for memzone.
> >
> > I don't quite like the idea of having a special entry with a different type
> > in an element list. Despite it is simpler for a locking perspective, it is
> > less obvious for the developper.
> >
> > Also, I changed the way a zone is reserved to return the one that have the
> > less impact on next reservation, and I feel it is easier to implement with
> > the shared memory.
> >
> > So, I just moved the init_shared_mem() inside the rte_mcfg_tailq_write_lock(),
> > it should do the job.
>
> Yep, that should work too, I think.
>
> >
> >
> > > > + if (params->size >= sizeof(struct rte_mbuf)) {
> > > > + rte_errno = EINVAL;
> > > > + goto fail;
> > > > + }
> > > > + if (!rte_is_power_of_2(params->align)) {
> > > > + rte_errno = EINVAL;
> > > > + goto fail;
> > > > + }
> > > > + if (params->flags != 0) {
> > > > + rte_errno = EINVAL;
> > > > + goto fail;
> > > > + }
> > > > +
> > > > + rte_mcfg_tailq_write_lock();
> > > > +
> > >
> > > I think it probably would be cleaner and easier to read/maintain, if you'll put actual
> > > code under lock protection into a separate function - as you did for __mbuf_dynfield_lookup().
> >
> > Yes, I did that, it should be clearer now.
> >
> >
@@ -28,6 +28,7 @@
#include <rte_random.h>
#include <rte_cycles.h>
#include <rte_malloc.h>
+#include <rte_mbuf_dyn.h>
#include "test.h"
@@ -502,7 +503,6 @@ test_attach_from_different_pool(struct rte_mempool *pktmbuf_pool,
rte_pktmbuf_free(clone2);
return -1;
}
-#undef GOTO_FAIL
/*
* test allocation and free of mbufs
@@ -1121,6 +1121,112 @@ test_tx_offload(void)
return (v1 == v2) ? 0 : -EINVAL;
}
+static int
+test_mbuf_dyn(struct rte_mempool *pktmbuf_pool)
+{
+ const struct rte_mbuf_dynfield dynfield = {
+ .name = "test-dynfield",
+ .size = sizeof(uint8_t),
+ .align = __alignof__(uint8_t),
+ .flags = 0,
+ };
+ const struct rte_mbuf_dynfield dynfield2 = {
+ .name = "test-dynfield2",
+ .size = sizeof(uint16_t),
+ .align = __alignof__(uint16_t),
+ .flags = 0,
+ };
+ const struct rte_mbuf_dynfield dynfield_fail_big = {
+ .name = "test-dynfield-fail-big",
+ .size = 256,
+ .align = 1,
+ .flags = 0,
+ };
+ const struct rte_mbuf_dynfield dynfield_fail_align = {
+ .name = "test-dynfield-fail-align",
+ .size = 1,
+ .align = 3,
+ .flags = 0,
+ };
+ const struct rte_mbuf_dynflag dynflag = {
+ .name = "test-dynflag",
+ .flags = 0,
+ };
+ const struct rte_mbuf_dynflag dynflag2 = {
+ .name = "test-dynflag2",
+ .flags = 0,
+ };
+ struct rte_mbuf *m = NULL;
+ int offset, offset2;
+ int flag, flag2;
+
+ printf("Test mbuf dynamic fields and flags\n");
+
+ offset = rte_mbuf_dynfield_register(&dynfield);
+ if (offset == -1)
+ GOTO_FAIL("failed to register dynamic field, offset=%d: %s",
+ offset, strerror(errno));
+
+ offset2 = rte_mbuf_dynfield_register(&dynfield);
+ if (offset2 != offset)
+ GOTO_FAIL("failed to lookup dynamic field, offset=%d, offset2=%d: %s",
+ offset, offset2, strerror(errno));
+
+ offset2 = rte_mbuf_dynfield_register(&dynfield2);
+ if (offset2 == -1 || offset2 == offset || (offset & 1))
+ GOTO_FAIL("failed to register dynfield field 2, offset=%d, offset2=%d: %s",
+ offset, offset2, strerror(errno));
+
+ printf("dynfield: offset = %d, offset2 = %d\n", offset, offset2);
+
+ offset = rte_mbuf_dynfield_register(&dynfield_fail_big);
+ if (offset != -1)
+ GOTO_FAIL("dynamic field creation should fail (too big)");
+
+ offset = rte_mbuf_dynfield_register(&dynfield_fail_align);
+ if (offset != -1)
+ GOTO_FAIL("dynamic field creation should fail (bad alignment)");
+
+ flag = rte_mbuf_dynflag_register(&dynflag);
+ if (flag == -1)
+ GOTO_FAIL("failed to register dynamic field, flag=%d: %s",
+ flag, strerror(errno));
+
+ flag2 = rte_mbuf_dynflag_register(&dynflag);
+ if (flag2 != flag)
+ GOTO_FAIL("failed to lookup dynamic field, flag=%d, flag2=%d: %s",
+ flag, flag2, strerror(errno));
+
+ flag2 = rte_mbuf_dynflag_register(&dynflag2);
+ if (flag2 == -1 || flag2 == flag)
+ GOTO_FAIL("failed to register dynflag field 2, flag=%d, flag2=%d: %s",
+ flag, flag2, strerror(errno));
+
+ printf("dynflag: flag = %d, flag2 = %d\n", flag, flag2);
+
+ /* set, get dynamic field */
+ m = rte_pktmbuf_alloc(pktmbuf_pool);
+ if (m == NULL)
+ GOTO_FAIL("Cannot allocate mbuf");
+
+ *RTE_MBUF_DYNFIELD(m, offset, uint8_t *) = 1;
+ if (*RTE_MBUF_DYNFIELD(m, offset, uint8_t *) != 1)
+ GOTO_FAIL("failed to read dynamic field");
+ *RTE_MBUF_DYNFIELD(m, offset2, uint16_t *) = 1000;
+ if (*RTE_MBUF_DYNFIELD(m, offset2, uint16_t *) != 1000)
+ GOTO_FAIL("failed to read dynamic field");
+
+ /* set a dynamic flag */
+ m->ol_flags |= (1ULL << flag);
+
+ rte_pktmbuf_free(m);
+ return 0;
+fail:
+ rte_pktmbuf_free(m);
+ return -1;
+}
+#undef GOTO_FAIL
+
static int
test_mbuf(void)
{
@@ -1140,6 +1246,12 @@ test_mbuf(void)
goto err;
}
+ /* test registration of dynamic fields and flags */
+ if (test_mbuf_dyn(pktmbuf_pool) < 0) {
+ printf("mbuf dynflag test failed\n");
+ goto err;
+ }
+
/* create a specific pktmbuf pool with a priv_size != 0 and no data
* room size */
pktmbuf_pool2 = rte_pktmbuf_pool_create("test_pktmbuf_pool2",
@@ -56,6 +56,13 @@ New Features
Also, make sure to start the actual text at the margin.
=========================================================
+* **Add support of support dynamic fields and flags in mbuf.**
+
+ This new feature adds the ability to dynamically register some room
+ for a field or a flag in the mbuf structure. This is typically used
+ for specific offload features, where adding a static field or flag
+ in the mbuf is not justified.
+
Removed Items
-------------
@@ -17,8 +17,10 @@ LIBABIVER := 5
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_MBUF) := rte_mbuf.c rte_mbuf_ptype.c rte_mbuf_pool_ops.c
+SRCS-$(CONFIG_RTE_LIBRTE_MBUF) += rte_mbuf_dyn.c
# install includes
SYMLINK-$(CONFIG_RTE_LIBRTE_MBUF)-include := rte_mbuf.h rte_mbuf_ptype.h rte_mbuf_pool_ops.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_MBUF)-include += rte_mbuf_dyn.h
include $(RTE_SDK)/mk/rte.lib.mk
@@ -2,8 +2,10 @@
# Copyright(c) 2017 Intel Corporation
version = 5
-sources = files('rte_mbuf.c', 'rte_mbuf_ptype.c', 'rte_mbuf_pool_ops.c')
-headers = files('rte_mbuf.h', 'rte_mbuf_ptype.h', 'rte_mbuf_pool_ops.h')
+sources = files('rte_mbuf.c', 'rte_mbuf_ptype.c', 'rte_mbuf_pool_ops.c',
+ 'rte_mbuf_dyn.c')
+headers = files('rte_mbuf.h', 'rte_mbuf_ptype.h', 'rte_mbuf_pool_ops.h',
+ 'rte_mbuf_dyn.h')
deps += ['mempool']
allow_experimental_apis = true
@@ -198,9 +198,12 @@ extern "C" {
#define PKT_RX_OUTER_L4_CKSUM_GOOD (1ULL << 22)
#define PKT_RX_OUTER_L4_CKSUM_INVALID ((1ULL << 21) | (1ULL << 22))
-/* add new RX flags here */
+/* add new RX flags here, don't forget to update PKT_FIRST_FREE */
-/* add new TX flags here */
+#define PKT_FIRST_FREE (1ULL << 23)
+#define PKT_LAST_FREE (1ULL << 39)
+
+/* add new TX flags here, don't forget to update PKT_LAST_FREE */
/**
* Indicate that the metadata field in the mbuf is in use.
@@ -738,6 +741,8 @@ struct rte_mbuf {
*/
struct rte_mbuf_ext_shared_info *shinfo;
+ uint64_t dynfield1; /**< Reserved for dynamic fields. */
+ uint64_t dynfield2; /**< Reserved for dynamic fields. */
} __rte_cache_aligned;
/**
@@ -1684,6 +1689,21 @@ rte_pktmbuf_attach_extbuf(struct rte_mbuf *m, void *buf_addr,
*/
#define rte_pktmbuf_detach_extbuf(m) rte_pktmbuf_detach(m)
+/**
+ * Copy dynamic fields from m_src to m_dst.
+ *
+ * @param m_dst
+ * The destination mbuf.
+ * @param m_src
+ * The source mbuf.
+ */
+static inline void
+rte_mbuf_dynfield_copy(struct rte_mbuf *m_dst, const struct rte_mbuf *m_src)
+{
+ m_dst->dynfield1 = m_src->dynfield1;
+ m_dst->dynfield2 = m_src->dynfield2;
+}
+
/**
* Attach packet mbuf to another packet mbuf.
*
@@ -1732,6 +1752,7 @@ static inline void rte_pktmbuf_attach(struct rte_mbuf *mi, struct rte_mbuf *m)
mi->vlan_tci_outer = m->vlan_tci_outer;
mi->tx_offload = m->tx_offload;
mi->hash = m->hash;
+ rte_mbuf_dynfield_copy(mi, m);
mi->next = NULL;
mi->pkt_len = mi->data_len;
new file mode 100644
@@ -0,0 +1,408 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2019 6WIND S.A.
+ */
+
+#include <sys/queue.h>
+
+#include <rte_common.h>
+#include <rte_eal.h>
+#include <rte_eal_memconfig.h>
+#include <rte_tailq.h>
+#include <rte_errno.h>
+#include <rte_malloc.h>
+#include <rte_string_fns.h>
+#include <rte_mbuf.h>
+#include <rte_mbuf_dyn.h>
+
+#define RTE_MBUF_DYN_MZNAME "rte_mbuf_dyn"
+
+struct mbuf_dynfield_elt {
+ TAILQ_ENTRY(mbuf_dynfield_elt) next;
+ struct rte_mbuf_dynfield params;
+ int offset;
+};
+TAILQ_HEAD(mbuf_dynfield_list, rte_tailq_entry);
+
+static struct rte_tailq_elem mbuf_dynfield_tailq = {
+ .name = "RTE_MBUF_DYNFIELD",
+};
+EAL_REGISTER_TAILQ(mbuf_dynfield_tailq);
+
+struct mbuf_dynflag_elt {
+ TAILQ_ENTRY(mbuf_dynflag_elt) next;
+ struct rte_mbuf_dynflag params;
+ int bitnum;
+};
+TAILQ_HEAD(mbuf_dynflag_list, rte_tailq_entry);
+
+static struct rte_tailq_elem mbuf_dynflag_tailq = {
+ .name = "RTE_MBUF_DYNFLAG",
+};
+EAL_REGISTER_TAILQ(mbuf_dynflag_tailq);
+
+struct mbuf_dyn_shm {
+ /** For each mbuf byte, free_space[i] == 1 if space is free. */
+ uint8_t free_space[sizeof(struct rte_mbuf)];
+ /** Bitfield of available flags. */
+ uint64_t free_flags;
+};
+static struct mbuf_dyn_shm *shm;
+
+/* allocate and initialize the shared memory */
+static int
+init_shared_mem(void)
+{
+ const struct rte_memzone *mz;
+ uint64_t mask;
+
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+ mz = rte_memzone_reserve_aligned(RTE_MBUF_DYN_MZNAME,
+ sizeof(struct mbuf_dyn_shm),
+ SOCKET_ID_ANY, 0,
+ RTE_CACHE_LINE_SIZE);
+ } else {
+ mz = rte_memzone_lookup(RTE_MBUF_DYN_MZNAME);
+ }
+ if (mz == NULL)
+ return -1;
+
+ shm = mz->addr;
+
+#define mark_free(field) \
+ memset(&shm->free_space[offsetof(struct rte_mbuf, field)], \
+ 0xff, sizeof(((struct rte_mbuf *)0)->field))
+
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+ /* init free_space, keep it sync'd with
+ * rte_mbuf_dynfield_copy().
+ */
+ memset(shm, 0, sizeof(*shm));
+ mark_free(dynfield1);
+ mark_free(dynfield2);
+
+ /* init free_flags */
+ for (mask = PKT_FIRST_FREE; mask <= PKT_LAST_FREE; mask <<= 1)
+ shm->free_flags |= mask;
+ }
+#undef mark_free
+
+ return 0;
+}
+
+/* check if this offset can be used */
+static int
+check_offset(size_t offset, size_t size, size_t align, unsigned int flags)
+{
+ size_t i;
+
+ (void)flags;
+
+ if ((offset & (align - 1)) != 0)
+ return -1;
+ if (offset + size > sizeof(struct rte_mbuf))
+ return -1;
+
+ for (i = 0; i < size; i++) {
+ if (!shm->free_space[i + offset])
+ return -1;
+ }
+
+ return 0;
+}
+
+/* assume tailq is locked */
+static struct mbuf_dynfield_elt *
+__mbuf_dynfield_lookup(const char *name)
+{
+ struct mbuf_dynfield_list *mbuf_dynfield_list;
+ struct mbuf_dynfield_elt *mbuf_dynfield;
+ struct rte_tailq_entry *te;
+
+ mbuf_dynfield_list = RTE_TAILQ_CAST(
+ mbuf_dynfield_tailq.head, mbuf_dynfield_list);
+
+ TAILQ_FOREACH(te, mbuf_dynfield_list, next) {
+ mbuf_dynfield = (struct mbuf_dynfield_elt *)te->data;
+ if (strcmp(name, mbuf_dynfield->params.name) == 0)
+ break;
+ }
+
+ if (te == NULL) {
+ rte_errno = ENOENT;
+ return NULL;
+ }
+
+ return mbuf_dynfield;
+}
+
+int
+rte_mbuf_dynfield_lookup(const char *name, struct rte_mbuf_dynfield *params)
+{
+ struct mbuf_dynfield_elt *mbuf_dynfield;
+
+ if (shm == NULL) {
+ rte_errno = ENOENT;
+ return -1;
+ }
+
+ rte_mcfg_tailq_read_lock();
+ mbuf_dynfield = __mbuf_dynfield_lookup(name);
+ rte_mcfg_tailq_read_unlock();
+
+ if (mbuf_dynfield == NULL) {
+ rte_errno = ENOENT;
+ return -1;
+ }
+
+ if (params != NULL)
+ memcpy(params, &mbuf_dynfield->params, sizeof(*params));
+
+ return mbuf_dynfield->offset;
+}
+
+static int mbuf_dynfield_cmp(const struct rte_mbuf_dynfield *params1,
+ const struct rte_mbuf_dynfield *params2)
+{
+ if (strcmp(params1->name, params2->name))
+ return -1;
+ if (params1->size != params2->size)
+ return -1;
+ if (params1->align != params2->align)
+ return -1;
+ if (params1->flags != params2->flags)
+ return -1;
+ return 0;
+}
+
+int
+rte_mbuf_dynfield_register(const struct rte_mbuf_dynfield *params)
+{
+ struct mbuf_dynfield_list *mbuf_dynfield_list;
+ struct mbuf_dynfield_elt *mbuf_dynfield = NULL;
+ struct rte_tailq_entry *te = NULL;
+ int offset, ret;
+ size_t i;
+
+ if (shm == NULL && init_shared_mem() < 0)
+ goto fail;
+ if (params->size >= sizeof(struct rte_mbuf)) {
+ rte_errno = EINVAL;
+ goto fail;
+ }
+ if (!rte_is_power_of_2(params->align)) {
+ rte_errno = EINVAL;
+ goto fail;
+ }
+ if (params->flags != 0) {
+ rte_errno = EINVAL;
+ goto fail;
+ }
+
+ rte_mcfg_tailq_write_lock();
+
+ mbuf_dynfield = __mbuf_dynfield_lookup(params->name);
+ if (mbuf_dynfield != NULL) {
+ if (mbuf_dynfield_cmp(params, &mbuf_dynfield->params) < 0) {
+ rte_errno = EEXIST;
+ goto fail_unlock;
+ }
+ offset = mbuf_dynfield->offset;
+ goto out_unlock;
+ }
+
+ if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
+ rte_errno = EPERM;
+ goto fail_unlock;
+ }
+
+ for (offset = 0;
+ offset < (int)sizeof(struct rte_mbuf);
+ offset++) {
+ if (check_offset(offset, params->size, params->align,
+ params->flags) == 0)
+ break;
+ }
+
+ if (offset == sizeof(struct rte_mbuf)) {
+ rte_errno = ENOENT;
+ goto fail_unlock;
+ }
+
+ mbuf_dynfield_list = RTE_TAILQ_CAST(
+ mbuf_dynfield_tailq.head, mbuf_dynfield_list);
+
+ te = rte_zmalloc("MBUF_DYNFIELD_TAILQ_ENTRY", sizeof(*te), 0);
+ if (te == NULL)
+ goto fail_unlock;
+
+ mbuf_dynfield = rte_zmalloc("mbuf_dynfield", sizeof(*mbuf_dynfield), 0);
+ if (mbuf_dynfield == NULL)
+ goto fail_unlock;
+
+ ret = strlcpy(mbuf_dynfield->params.name, params->name,
+ sizeof(mbuf_dynfield->params.name));
+ if (ret < 0 || ret >= (int)sizeof(mbuf_dynfield->params.name)) {
+ rte_errno = ENAMETOOLONG;
+ goto fail_unlock;
+ }
+ memcpy(&mbuf_dynfield->params, params, sizeof(mbuf_dynfield->params));
+ mbuf_dynfield->offset = offset;
+ te->data = mbuf_dynfield;
+
+ TAILQ_INSERT_TAIL(mbuf_dynfield_list, te, next);
+
+ for (i = offset; i < offset + params->size; i++)
+ shm->free_space[i] = 0;
+
+ RTE_LOG(DEBUG, MBUF, "Registered dynamic field %s (sz=%zu, al=%zu, fl=0x%x) -> %d\n",
+ params->name, params->size, params->align, params->flags,
+ offset);
+
+out_unlock:
+ rte_mcfg_tailq_write_unlock();
+
+ return offset;
+
+fail_unlock:
+ rte_mcfg_tailq_write_unlock();
+fail:
+ rte_free(mbuf_dynfield);
+ rte_free(te);
+ return -1;
+}
+
+/* assume tailq is locked */
+static struct mbuf_dynflag_elt *
+__mbuf_dynflag_lookup(const char *name)
+{
+ struct mbuf_dynflag_list *mbuf_dynflag_list;
+ struct mbuf_dynflag_elt *mbuf_dynflag;
+ struct rte_tailq_entry *te;
+
+ mbuf_dynflag_list = RTE_TAILQ_CAST(
+ mbuf_dynflag_tailq.head, mbuf_dynflag_list);
+
+ TAILQ_FOREACH(te, mbuf_dynflag_list, next) {
+ mbuf_dynflag = (struct mbuf_dynflag_elt *)te->data;
+ if (strncmp(name, mbuf_dynflag->params.name,
+ RTE_MBUF_DYN_NAMESIZE) == 0)
+ break;
+ }
+
+ if (te == NULL) {
+ rte_errno = ENOENT;
+ return NULL;
+ }
+
+ return mbuf_dynflag;
+}
+
+int
+rte_mbuf_dynflag_lookup(const char *name,
+ struct rte_mbuf_dynflag *params)
+{
+ struct mbuf_dynflag_elt *mbuf_dynflag;
+
+ if (shm == NULL) {
+ rte_errno = ENOENT;
+ return -1;
+ }
+
+ rte_mcfg_tailq_read_lock();
+ mbuf_dynflag = __mbuf_dynflag_lookup(name);
+ rte_mcfg_tailq_read_unlock();
+
+ if (mbuf_dynflag == NULL) {
+ rte_errno = ENOENT;
+ return -1;
+ }
+
+ if (params != NULL)
+ memcpy(params, &mbuf_dynflag->params, sizeof(*params));
+
+ return mbuf_dynflag->bitnum;
+}
+
+static int mbuf_dynflag_cmp(const struct rte_mbuf_dynflag *params1,
+ const struct rte_mbuf_dynflag *params2)
+{
+ if (strcmp(params1->name, params2->name))
+ return -1;
+ if (params1->flags != params2->flags)
+ return -1;
+ return 0;
+}
+
+int
+rte_mbuf_dynflag_register(const struct rte_mbuf_dynflag *params)
+{
+ struct mbuf_dynflag_list *mbuf_dynflag_list;
+ struct mbuf_dynflag_elt *mbuf_dynflag = NULL;
+ struct rte_tailq_entry *te = NULL;
+ int bitnum, ret;
+
+ if (shm == NULL && init_shared_mem() < 0)
+ goto fail;
+
+ rte_mcfg_tailq_write_lock();
+
+ mbuf_dynflag = __mbuf_dynflag_lookup(params->name);
+ if (mbuf_dynflag != NULL) {
+ if (mbuf_dynflag_cmp(params, &mbuf_dynflag->params) < 0) {
+ rte_errno = EEXIST;
+ goto fail_unlock;
+ }
+ bitnum = mbuf_dynflag->bitnum;
+ goto out_unlock;
+ }
+
+ if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
+ rte_errno = EPERM;
+ goto fail_unlock;
+ }
+
+ if (shm->free_flags == 0) {
+ rte_errno = ENOENT;
+ goto fail_unlock;
+ }
+ bitnum = rte_bsf64(shm->free_flags);
+
+ mbuf_dynflag_list = RTE_TAILQ_CAST(
+ mbuf_dynflag_tailq.head, mbuf_dynflag_list);
+
+ te = rte_zmalloc("MBUF_DYNFLAG_TAILQ_ENTRY", sizeof(*te), 0);
+ if (te == NULL)
+ goto fail_unlock;
+
+ mbuf_dynflag = rte_zmalloc("mbuf_dynflag", sizeof(*mbuf_dynflag), 0);
+ if (mbuf_dynflag == NULL)
+ goto fail_unlock;
+
+ ret = strlcpy(mbuf_dynflag->params.name, params->name,
+ sizeof(mbuf_dynflag->params.name));
+ if (ret < 0 || ret >= (int)sizeof(mbuf_dynflag->params.name)) {
+ rte_errno = ENAMETOOLONG;
+ goto fail_unlock;
+ }
+ mbuf_dynflag->bitnum = bitnum;
+ te->data = mbuf_dynflag;
+
+ TAILQ_INSERT_TAIL(mbuf_dynflag_list, te, next);
+
+ shm->free_flags &= ~(1ULL << bitnum);
+
+ RTE_LOG(DEBUG, MBUF, "Registered dynamic flag %s (fl=0x%x) -> %u\n",
+ params->name, params->flags, bitnum);
+
+out_unlock:
+ rte_mcfg_tailq_write_unlock();
+
+ return bitnum;
+
+fail_unlock:
+ rte_mcfg_tailq_write_unlock();
+fail:
+ rte_free(mbuf_dynflag);
+ rte_free(te);
+ return -1;
+}
new file mode 100644
@@ -0,0 +1,163 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2019 6WIND S.A.
+ */
+
+#ifndef _RTE_MBUF_DYN_H_
+#define _RTE_MBUF_DYN_H_
+
+/**
+ * @file
+ * RTE Mbuf 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 module addresses this issue, 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, stored
+ * in mbuf->ol_flags.
+ *
+ * The typical use case is when a specific offload feature requires to
+ * register a dedicated offload field in the mbuf structure, and adding
+ * a static field or flag is not justified.
+ *
+ * Example of use:
+ *
+ * - A rte_mbuf_dynfield structure is defined, containing the parameters
+ * of the dynamic field to be registered:
+ * const struct rte_mbuf_dynfield rte_dynfield_my_feature = { ... };
+ * - The application initializes the PMD, and asks for this feature
+ * at port initialization by passing DEV_RX_OFFLOAD_MY_FEATURE in
+ * rxconf. This will make the PMD to register the field by calling
+ * rte_mbuf_dynfield_register(&rte_dynfield_my_feature). The PMD
+ * stores the returned offset.
+ * - The application that uses the offload feature also registers
+ * the field to retrieve the same offset.
+ * - When the PMD receives a packet, it can set the field:
+ * *RTE_MBUF_DYNFIELD(m, offset, <type *>) = value;
+ * - In the main loop, the application can retrieve the value with
+ * the same macro.
+ *
+ * To avoid wasting space, the dynamic fields or flags must only be
+ * reserved on demand, when an application asks for the related feature.
+ *
+ * The registration can be done at any moment, but it is not possible
+ * to unregister fields or flags for now.
+ *
+ * A dynamic field can be reserved and used by an application only.
+ * It can for instance be a packet mark.
+ */
+
+#include <sys/types.h>
+/**
+ * Maximum length of the dynamic field or flag string.
+ */
+#define RTE_MBUF_DYN_NAMESIZE 64
+
+/**
+ * Structure describing the parameters of a mbuf dynamic field.
+ */
+struct rte_mbuf_dynfield {
+ char name[RTE_MBUF_DYN_NAMESIZE]; /**< Name of the field. */
+ size_t size; /**< The number of bytes to reserve. */
+ size_t align; /**< The alignment constraint (power of 2). */
+ unsigned int flags; /**< Reserved for future use, must be 0. */
+};
+
+/**
+ * Structure describing the parameters of a mbuf dynamic flag.
+ */
+struct rte_mbuf_dynflag {
+ char name[RTE_MBUF_DYN_NAMESIZE]; /**< Name of the dynamic flag. */
+ unsigned int flags; /**< Reserved for future use, must be 0. */
+};
+
+/**
+ * Register space for a dynamic field in the mbuf structure.
+ *
+ * If the field is already registered (same name and parameters), its
+ * offset is returned.
+ *
+ * @param params
+ * A structure containing the requested parameters (name, size,
+ * alignment constraint and flags).
+ * @return
+ * The offset in the mbuf structure, or -1 on error.
+ * Possible values for rte_errno:
+ * - EINVAL: invalid parameters (size, align, or flags).
+ * - EEXIST: this name is already register with different parameters.
+ * - EPERM: called from a secondary process.
+ * - ENOENT: not enough room in mbuf.
+ * - ENOMEM: allocation failure.
+ * - ENAMETOOLONG: name does not ends with \0.
+ */
+__rte_experimental
+int rte_mbuf_dynfield_register(const struct rte_mbuf_dynfield *params);
+
+/**
+ * Lookup for a registered dynamic mbuf field.
+ *
+ * @param name
+ * A string identifying the dynamic field.
+ * @param params
+ * If not NULL, and if the lookup is successful, the structure is
+ * filled with the parameters of the dynamic field.
+ * @return
+ * The offset of this field in the mbuf structure, or -1 on error.
+ * Possible values for rte_errno:
+ * - ENOENT: no dynamic field matches this name.
+ */
+__rte_experimental
+int rte_mbuf_dynfield_lookup(const char *name,
+ struct rte_mbuf_dynfield *params);
+
+/**
+ * Register a dynamic flag in the mbuf structure.
+ *
+ * If the flag is already registered (same name and parameters), its
+ * offset is returned.
+ *
+ * @param params
+ * A structure containing the requested parameters of the dynamic
+ * flag (name and options).
+ * @return
+ * The number of the reserved bit, or -1 on error.
+ * Possible values for rte_errno:
+ * - EINVAL: invalid parameters (size, align, or flags).
+ * - EEXIST: this name is already register with different parameters.
+ * - EPERM: called from a secondary process.
+ * - ENOENT: no more flag available.
+ * - ENOMEM: allocation failure.
+ * - ENAMETOOLONG: name is longer than RTE_MBUF_DYN_NAMESIZE - 1.
+ */
+__rte_experimental
+int rte_mbuf_dynflag_register(const struct rte_mbuf_dynflag *params);
+
+/**
+ * Lookup for a registered dynamic mbuf flag.
+ *
+ * @param name
+ * A string identifying the dynamic flag.
+ * @param params
+ * If not NULL, and if the lookup is successful, the structure is
+ * filled with the parameters of the dynamic flag.
+ * @return
+ * The offset of this flag in the mbuf structure, or -1 on error.
+ * Possible values for rte_errno:
+ * - ENOENT: no dynamic flag matches this name.
+ */
+__rte_experimental
+int rte_mbuf_dynflag_lookup(const char *name,
+ struct rte_mbuf_dynflag *params);
+
+/**
+ * Helper macro to access to a dynamic field.
+ */
+#define RTE_MBUF_DYNFIELD(m, offset, type) ((type)((uintptr_t)(m) + (offset)))
+
+#endif
@@ -50,4 +50,8 @@ EXPERIMENTAL {
global:
rte_mbuf_check;
+ rte_mbuf_dynfield_lookup;
+ rte_mbuf_dynfield_register;
+ rte_mbuf_dynflag_lookup;
+ rte_mbuf_dynflag_register;
} DPDK_18.08;