From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH 2/7] rte_sched: use reserved field to allow more VLAN's Date: Mon, 2 Feb 2015 23:31:53 +0100 Message-ID: <20150202233153.690d1ea6@uryu.home.lan> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "dev-VfR2kkLFssw@public.gmane.org" , Stephen Hemminger To: "Ananyev, Konstantin" Return-path: In-Reply-To: <2601191342CEEE43887BDE71AB977258213E2822-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" On Mon, 2 Feb 2015 14:21:58 +0000 "Ananyev, Konstantin" wrote: > Hi Stephen, > > > -----Original Message----- > > From: dev [mailto:dev-bounces-VfR2kkLFssw@public.gmane.org] On Behalf Of Stephen Hemminger > > Sent: Sunday, February 01, 2015 10:04 AM > > To: dev-VfR2kkLFssw@public.gmane.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.