From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stephen@networkplumber.org>
Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com
[209.85.213.176]) by dpdk.org (Postfix) with ESMTP id 9BC9B2A61
for <dev@dpdk.org>; Mon, 2 Feb 2015 23:32:16 +0100 (CET)
Received: by mail-ig0-f176.google.com with SMTP id hl2so22134577igb.3
for <dev@dpdk.org>; Mon, 02 Feb 2015 14:32:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
:references:mime-version:content-type:content-transfer-encoding;
bh=9ASqLx0LMFeVEnnmoj7IHLCQPNwWHMOHZMj+i0OfSEA=;
b=eeu1fVtmEFQisryHGSikLd2xSgpRL8iSv8tYfqEooC0Bhwn4F+OI5Cw3yKl1pUvPcN
FoKwHypQE/BApSW+iVxKgLc5ed6lyrVRq7n7B7oxo666nGHs2pJhAQwmmgxzFXzEI7eX
w8bWR4TdEvXzsl7enNawUmTzzkgXtCfrThrdPDIkcCgqNWtYBjr+V4JaY5tEHND44mUZ
LYHDfSNNckIRGP4CJbtBoAnGmBvjNG4RQwQsVOiMGqn5IHTmaXwd6MMO4yowyG8sYan/
LBd61UZSt783SJphNs2zJZZX2ISCRJVpIU7HTF7v7eShFrEJcpf77PSmFGt+ILa0XF8N
cWMw==
X-Gm-Message-State: ALoCoQlT8/pZy8N310qoXXqwWi9ie2vwBdhEn4aN2Xt0CC9vUQwTyy8ZavesVIrHTmGga47ALNmq
X-Received: by 10.107.34.149 with SMTP id i143mr25312914ioi.1.1422916336055;
Mon, 02 Feb 2015 14:32:16 -0800 (PST)
Received: from uryu.home.lan (75-104-68-156.mobility.exede.net.
[75.104.68.156])
by mx.google.com with ESMTPSA id la3sm6893866igb.0.2015.02.02.14.32.11
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 02 Feb 2015 14:32:15 -0800 (PST)
Date: Mon, 2 Feb 2015 23:31:53 +0100
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Message-ID: <20150202233153.690d1ea6@uryu.home.lan>
In-Reply-To: <2601191342CEEE43887BDE71AB977258213E2822@irsmsx105.ger.corp.intel.com>
References: <1422785031-11494-1-git-send-email-stephen@networkplumber.org>
<1422785031-11494-2-git-send-email-stephen@networkplumber.org>
<2601191342CEEE43887BDE71AB977258213E2822@irsmsx105.ger.corp.intel.com>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Feb 2015 22:32:17 -0000
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.
The reserved field is not use upstream merged code and therefore is fair game.
First to claim it wins.