> -----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
