From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; Mon, 2 Feb 2015 23:32:16 +0100 (CET) Received: by mail-ig0-f176.google.com with SMTP id hl2so22134577igb.3 for ; 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 To: "Ananyev, Konstantin" 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" , Stephen Hemminger 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 22:32:17 -0000 On Mon, 2 Feb 2015 14:21:58 +0000 "Ananyev, Konstantin" 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 > > > > 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 > > --- > > 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.