Re: [dpdk-dev] [RFC 4/4] net/ether: use bitops to speedup comparison

DPDK patches and discussions
 help / color / mirror / Atom feed

From: Bruce Richardson <bruce.richardson@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [RFC 4/4] net/ether: use bitops to speedup comparison
Date: Thu, 16 May 2019 21:37:42 +0100	[thread overview]
Message-ID: <20190516203742.GB642@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <20190516100454.36e7bc88@hermes.lan>

On Thu, May 16, 2019 at 10:04:54AM -0700, Stephen Hemminger wrote:
> On Thu, 16 May 2019 17:36:43 +0100
> Bruce Richardson <bruce.richardson@intel.com> wrote:
> 
> > On Thu, May 16, 2019 at 05:07:45PM +0100, Bruce Richardson wrote:
> > > On Thu, May 16, 2019 at 09:06:52AM -0700, Stephen Hemminger wrote:  
> > > > On Thu, 16 May 2019 17:03:37 +0100
> > > > Bruce Richardson <bruce.richardson@intel.com> wrote:
> > > >   
> > > > > On Wed, May 15, 2019 at 03:19:52PM -0700, Stephen Hemminger wrote:  
> > > > > > Using bit operations like or and xor is faster than a loop
> > > > > > on all architectures. Really just explicit unrolling.
> > > > > > 
> > > > > > Similar cast to uint16 unaligned is already done in
> > > > > > other functions here.
> > > > > > 
> > > > > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > > > > ---
> > > > > >  lib/librte_net/rte_ether.h | 17 +++++++----------
> > > > > >  1 file changed, 7 insertions(+), 10 deletions(-)
> > > > > >     
> > > > > Rather than casting to unaligned values, which gives compiler warnings in
> > > > > some cases, I believe we should just mark the ethernet addresses as always
> > > > > being 2-byte aligned and simplify things. [unless we have a good use case
> > > > > where we won't have 2-byte alignment???].
> > > > > 
> > > > > See patch: http://patches.dpdk.org/patch/53482/
> > > > > 
> > > > > Regards,
> > > > > /Bruce  
> > > > 
> > > > I agree. Then you could also remove the unaligned_uint16_t that
> > > > already exists in rte_ether.h
> > > > 
> > > > Do you want me to put your patch in my series?  
> > > 
> > > Sure, feel free.
> > >   
> > 
> > I've just found another problem in this area. Compiling l2fwd with gcc 9, I
> > get:
> > 
> > main.c:164:54: warning: taking address of packed member of ‘struct ether_hdr’ may result in an unaligned pointer value [-Waddress-of-packed-member]
> >   164 |  ether_addr_copy(&l2fwd_ports_eth_addr[dest_portid], &eth->s_addr);
> >       | 
> > 
> > Looking at some of the structures, it appears that not all the packet
> > attributes may be necessary. For example, while AFAIK there are not
> > absolute guarantees about structure padding, for all compilers I remember
> > using the following changes are safe:
> > 
> > diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
> > index 8090b7c01..7d9f34791 100644
> > --- a/lib/librte_net/rte_ether.h
> > +++ b/lib/librte_net/rte_ether.h
> > @@ -57,7 +57,7 @@ extern "C" {
> >  struct ether_addr {
> >         /** Addr bytes in tx order */
> >         uint8_t addr_bytes[ETHER_ADDR_LEN] __rte_aligned(2);
> > -} __attribute__((__packed__));
> > +};
> > 
> >  #define ETHER_LOCAL_ADMIN_ADDR 0x02 /**< Locally assigned Eth. address. */
> >  #define ETHER_GROUP_ADDR       0x01 /**< Multicast or broadcast Eth. address. */
> > @@ -273,7 +273,7 @@ struct ether_hdr {
> >         struct ether_addr d_addr; /**< Destination address. */
> >         struct ether_addr s_addr; /**< Source address. */
> >         uint16_t ether_type;      /**< Frame type. */
> > -} __attribute__((__packed__));
> > +};
> > 
> >  /**
> >   * Ethernet VLAN Header.
> > @@ -283,7 +283,7 @@ struct ether_hdr {
> >  struct vlan_hdr {
> >         uint16_t vlan_tci; /**< Priority (3) + CFI (1) + Identifier Code (12) */
> >         uint16_t eth_proto;/**< Ethernet type of encapsulated frame. */
> > -} __attribute__((__packed__));
> > +};
> > 
> >  /**
> >   * VXLAN protocol header.
> > 
> > I think we therefore should consider removing those packed attributes to
> > avoid application warnings.
> > 
> > /Bruce
> 
> Agree if structure is naturally packed, adding packed attribute is a mistake.

Do you want to also include such a change in your patchset, or will I do up
a patch for it - perhaps a two-patch set with this and my previous alignment
patch?

next prev parent reply	other threads:[~2019-05-16 20:37 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-15 22:19 [dpdk-dev] [RFC 0/4] net/ether: improvements Stephen Hemminger
2019-05-15 22:19 ` Stephen Hemminger
2019-05-15 22:19 ` [dpdk-dev] [RFC 1/4] net/ether: deinline non-critical functions Stephen Hemminger
2019-05-15 22:19   ` Stephen Hemminger
2019-05-16  7:10   ` David Marchand
2019-05-16  7:10     ` David Marchand
2019-05-15 22:19 ` [dpdk-dev] [RFC 2/4] net/ether: add eth_unformat_addr Stephen Hemminger
2019-05-15 22:19   ` Stephen Hemminger
2019-05-16  7:28   ` David Marchand
2019-05-16  7:28     ` David Marchand
2019-05-15 22:19 ` [dpdk-dev] [RFC 3/4] ethdev: use eth_unformat_addr Stephen Hemminger
2019-05-15 22:19   ` Stephen Hemminger
2019-05-16  7:32   ` David Marchand
2019-05-16  7:32     ` David Marchand
2019-05-16 10:19   ` Bruce Richardson
2019-05-16 10:19     ` Bruce Richardson
2019-05-15 22:19 ` [dpdk-dev] [RFC 4/4] net/ether: use bitops to speedup comparison Stephen Hemminger
2019-05-15 22:19   ` Stephen Hemminger
2019-05-16  9:03   ` Mattias Rönnblom
2019-05-16  9:03     ` Mattias Rönnblom
2019-05-16 15:32     ` Stephen Hemminger
2019-05-16 16:03   ` Bruce Richardson
2019-05-16 16:06     ` Stephen Hemminger
2019-05-16 16:07       ` Bruce Richardson
2019-05-16 16:36         ` Bruce Richardson
2019-05-16 17:04           ` Stephen Hemminger
2019-05-16 20:37             ` Bruce Richardson [this message]
2019-05-16 20:41               ` Bruce Richardson

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=20190516203742.GB642@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=stephen@networkplumber.org \
    /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).