From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Stephen Hemminger <shemming@brocade.com>
Subject: Re: [dpdk-dev] [PATCH 2/7] rte_sched: use reserved field to allow more VLAN's
Date: Tue, 3 Feb 2015 00:07:50 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB977258213E299C@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <20150202233153.690d1ea6@uryu.home.lan>
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Monday, February 02, 2015 10:32 PM
> To: Ananyev, Konstantin
> Cc: dev@dpdk.org; Stephen Hemminger
> Subject: Re: [dpdk-dev] [PATCH 2/7] rte_sched: use reserved field to allow more VLAN's
>
> On Mon, 2 Feb 2015 14:21:58 +0000
> "Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
>
> > Hi Stephen,
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger
> > > Sent: Sunday, February 01, 2015 10:04 AM
> > > To: dev@dpdk.org
> > > Cc: Stephen Hemminger
> > > Subject: [dpdk-dev] [PATCH 2/7] rte_sched: use reserved field to allow more VLAN's
> > >
> > > From: Stephen Hemminger <shemming@brocade.com>
> > >
> > > The QoS subport is limited to 8 bits in original code.
> > > But customers demanded ability to support full number of VLAN's (4096)
> > > therefore use reserved field of mbuf for this field instead
> > > of packing inside other classify portions.
> > >
> > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > ---
> > > lib/librte_mbuf/rte_mbuf.h | 2 +-
> > > lib/librte_sched/rte_sched.h | 31 ++++++++++++++++++++-----------
> > > 2 files changed, 21 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> > > index 16059c6..b6b08f4 100644
> > > --- a/lib/librte_mbuf/rte_mbuf.h
> > > +++ b/lib/librte_mbuf/rte_mbuf.h
> > > @@ -242,7 +242,7 @@ struct rte_mbuf {
> > > uint16_t data_len; /**< Amount of data in segment buffer. */
> > > uint32_t pkt_len; /**< Total pkt len: sum of all segments. */
> > > uint16_t vlan_tci; /**< VLAN Tag Control Identifier (CPU order) */
> > > - uint16_t reserved;
> > > + uint16_t subport; /**< SCHED Subport ID */
> >
> > As I remember, we keep these reserved 2 bytes for RX 2 double vlan tag offload.
> > So probably not a good idea to use it for something that is rte_sched specific.
> > If you really need extra space fo rte_sched fields inside mbuf, can't you move it into second cache line?
> > Or might be you can use userdata, to either store sched information directly, or as a pointer to some external memory location?
> > Another possibility - union mbuf.hash is 64bit now, while sched uses only 32bits.
> > So might be you can rearrange it to make sched 64bits too?
> > Something like:
> >
> > union {
> > uint32_t rss; /**< RSS hash result if RSS enabled */
> > struct {
> > union {
> > struct {
> > uint16_t hash;
> > uint16_t id;
> > };
> > uint32_t lo;
> > /**< Second 4 flexible bytes */
> > };
> > uint32_t hi;
> > /**< First 4 flexible bytes or FD ID, dependent on
> > PKT_RX_FDIR_* flag in ol_flags. */
> > } fdir; /**< Filter identifier if FDIR enabled */
> > - uint32_t sched; /**< Hierarchical scheduler */
> > + uint64_t sched; /**< Hierarchical scheduler */
> > uint32_t usr; /**< User defined tags. See @rte_distributor_p
> > rocess */
> > } hash; /**< hash information */
>
> Increasing the size of that union totally breaks other alignment and is a not starter.
struct fdir already is 64bit width.
Though yes, we can't use uint64_t directly, as it would break alignment - totally forgot about it.
But nothing prevents you from doing:
struct { uint32_t lo, hi;} sched;
right?
>
> The reserved field is not use upstream merged code and therefore is fair game.
As you can see that reserved field lies inside first 16B from rx_descriptor_fields1;
So hopefully we will be able to load it from RX descriptors in one SSE load/store together with
other RXD fields.
Anyway these 16B are supposed to contain fields that are filled by RXD (as the name suggests).
> First to claim it wins.
Wins what?
Sorry, but you can't pollute mbuf structure with whatever you like.
So NACK for now.
Konstantin
next prev parent reply other threads:[~2015-02-03 0:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-01 10:03 [dpdk-dev] [PATCH 1/7] rte_sched: make RED optional at runtime Stephen Hemminger
2015-02-01 10:03 ` [dpdk-dev] [PATCH 2/7] rte_sched: use reserved field to allow more VLAN's Stephen Hemminger
[not found] ` <2601191342CEEE43887BDE71AB977258213E2822@irsmsx105.ger.corp.intel.com>
2015-02-02 22:31 ` Stephen Hemminger
2015-02-03 0:07 ` Ananyev, Konstantin [this message]
2015-02-01 10:03 ` [dpdk-dev] [PATCH 3/7] rte_sched: keep track of RED drops Stephen Hemminger
2015-02-01 10:03 ` [dpdk-dev] [PATCH 4/7] rte_sched: don't clear statistics when read Stephen Hemminger
2015-02-01 14:25 ` Neil Horman
2015-02-01 10:03 ` [dpdk-dev] [PATCH 5/7] rte_sched: don't put tabs in log messages Stephen Hemminger
2015-02-01 10:03 ` [dpdk-dev] [PATCH 6/7] rte_sched: eliminate floating point in calculating byte clock Stephen Hemminger
2015-02-01 10:03 ` [dpdk-dev] [PATCH 7/7] rte_sched: rearrange data structures Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2601191342CEEE43887BDE71AB977258213E299C@irsmsx105.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=dev@dpdk.org \
--cc=shemming@brocade.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).