[dpdk-dev] [PATCH 2/7] rte_sched: use reserved field to allow more VLAN's

[Ananyev, Konstantin]

> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Monday, February 02, 2015 10:32 PM
> To: Ananyev, Konstantin
> Cc: dev at 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 at intel.com> wrote:
> 
> > Hi Stephen,
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger
> > > Sent: Sunday, February 01, 2015 10:04 AM
> > > To: dev at 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 at 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 at 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