DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>, talshn@mellanox.com
Cc: dev@dpdk.org, pallavi.kadam@intel.com, ranjit.menon@intel.com,
	navasile@linux.microsoft.com, olivier.matz@6wind.com,
	harini.ramakrishnan@microsoft.com, ocardona@microsoft.com,
	david.marchand@redhat.com, arybchenko@solarflare.com,
	bruce.richardson@intel.com, jerinj@marvell.com,
	drc@linux.vnet.ibm.com, ruifeng.wang@arm.com,
	konstantin.ananyev@intel.com
Subject: Re: [dpdk-dev] [PATCH] mbuf: align rte_mbuf for Windows
Date: Tue, 19 May 2020 22:18:57 +0200	[thread overview]
Message-ID: <1935350.G7KYNPxu0G@thomas> (raw)
In-Reply-To: <20200519225753.56c663ac@sovereign>

19/05/2020 21:57, Dmitry Kozlyuk:
> On Tue, 19 May 2020 20:49:50 +0200
> Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> > +Cc more maintainers
> > 
> > 19/05/2020 20:41, talshn@mellanox.com:
> > > From: Tal Shnaiderman <talshn@mellanox.com>
> > > 
> > > Using uint32_t type bit-fields in Windows will pads the
> > > 'L2/L3/L4 and tunnel information' union with additional bits.
> > > 
> > > This padding causes rte_mbuf size misalignment and the total size
> > > increases to 3 cache-lines.
> > > 
> > > Changed packet_type bit-fields types from uint32_t to uint8_t
> > > to allow unified 2 cache-line structure size.
> > > 
> > > Added the __extension__ attribute over the modified struct to avoid
> > > the warning:
> > > 
> > > type of bit-field ... is a GCC extension [-pedantic]
> > > 
> > > Signed-off-by: Tal Shnaiderman <talshn@mellanox.com>
> > > ---
> > >  lib/librte_mbuf/rte_mbuf_core.h | 11 ++++++-----
> > >  1 file changed, 6 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/lib/librte_mbuf/rte_mbuf_core.h
> > > b/lib/librte_mbuf/rte_mbuf_core.h index b9a59c879..82441555e 100644
> > > --- a/lib/librte_mbuf/rte_mbuf_core.h
> > > +++ b/lib/librte_mbuf/rte_mbuf_core.h
> > > @@ -521,11 +521,12 @@ struct rte_mbuf {
> > >  	RTE_STD_C11
> > >  	union {
> > >  		uint32_t packet_type; /**< L2/L3/L4 and tunnel
> > > information. */
> > > +		__extension__
> > >  		struct {
> > > -			uint32_t l2_type:4; /**< (Outer) L2 type.
> > > */
> > > -			uint32_t l3_type:4; /**< (Outer) L3 type.
> > > */
> > > -			uint32_t l4_type:4; /**< (Outer) L4 type.
> > > */
> > > -			uint32_t tun_type:4; /**< Tunnel type. */
> > > +			uint8_t l2_type:4; /**< (Outer) L2 type. */
> > > +			uint8_t l3_type:4; /**< (Outer) L3 type. */
> > > +			uint8_t l4_type:4; /**< (Outer) L4 type. */
> > > +			uint8_t tun_type:4; /**< Tunnel type. */
> > >  			RTE_STD_C11
> > >  			union {
> > >  				uint8_t inner_esp_next_proto;
> > > @@ -541,7 +542,7 @@ struct rte_mbuf {
> > >  					/**< Inner L3 type. */
> > >  				};
> > >  			};
> > > -			uint32_t inner_l4_type:4; /**< Inner L4
> > > type. */
> > > +			uint8_t inner_l4_type:4; /**< Inner L4
> > > type. */ };
> > >  	};  
> > 
> > 
> > 
> 
> Such a clean and simple solution to what seemed to require compiler
> workaround or fix! All offsets are equal on Windows and Linux for the
> following toolchains, x86_64:
> 
> * cross-compilation with MinGW-w64 6.0.0 GCC 9.3.0
> * Windows native MinGW-w64 6.0.0 GCC 8.1.0 and Clang 9.0.1
> 
> Tested-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>

Would be interesting to see an offset comparison in little and big endian.



  reply	other threads:[~2020-05-19 20:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 18:41 talshn
2020-05-19 18:49 ` Thomas Monjalon
2020-05-19 19:57   ` Dmitry Kozlyuk
2020-05-19 20:18     ` Thomas Monjalon [this message]
2020-05-19 22:15       ` Ranjit Menon
2020-06-11 11:43         ` Olivier Matz
2020-06-11 14:29           ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1935350.G7KYNPxu0G@thomas \
    --to=thomas@monjalon.net \
    --cc=arybchenko@solarflare.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=dmitry.kozliuk@gmail.com \
    --cc=drc@linux.vnet.ibm.com \
    --cc=harini.ramakrishnan@microsoft.com \
    --cc=jerinj@marvell.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=navasile@linux.microsoft.com \
    --cc=ocardona@microsoft.com \
    --cc=olivier.matz@6wind.com \
    --cc=pallavi.kadam@intel.com \
    --cc=ranjit.menon@intel.com \
    --cc=ruifeng.wang@arm.com \
    --cc=talshn@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).