From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 13489376E for ; Tue, 3 Feb 2015 01:07:54 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP; 02 Feb 2015 16:07:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,509,1418112000"; d="scan'208";a="679947792" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by orsmga002.jf.intel.com with ESMTP; 02 Feb 2015 16:07:52 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.81]) by IRSMSX154.ger.corp.intel.com ([169.254.12.111]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 00:07:50 +0000 From: "Ananyev, Konstantin" To: Stephen Hemminger Thread-Topic: [dpdk-dev] [PATCH 2/7] rte_sched: use reserved field to allow more VLAN's Thread-Index: AQHQPgZ2sf8kdb9ltUyJ+5jj5piuaZzdZ6ywgACMXYCAABQf4A== Date: Tue, 3 Feb 2015 00:07:50 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258213E299C@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> <20150202233153.690d1ea6@uryu.home.lan> In-Reply-To: <20150202233153.690d1ea6@uryu.home.lan> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Tue, 03 Feb 2015 00:07:55 -0000 > -----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 allo= w more VLAN's >=20 > On Mon, 2 Feb 2015 14:21:58 +0000 > "Ananyev, Konstantin" wrote: >=20 > > Hi Stephen, > > > > > -----Original Message----- > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminge= r > > > 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 allo= w 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 ord= er) */ > > > - 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 s= pecific. > > If you really need extra space fo rte_sched fields inside mbuf, can't y= ou move it into second cache line? > > Or might be you can use userdata, to either store sched information dir= ectly, or as a pointer to some external memory location? > > Another possibility - union mbuf.hash is 64bit now, while sched uses on= ly 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 enable= d */ > > - uint32_t sched; /**< Hierarchical scheduler */ > > + uint64_t sched; /**< Hierarchical scheduler */ > > uint32_t usr; /**< User defined tags. See @rte_dist= ributor_p > > rocess */ > > } hash; /**< hash information */ >=20 > 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 - t= otally forgot about it. But nothing prevents you from doing: struct { uint32_t lo, hi;} sched; right? >=20 > 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=20 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