All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sven Eckelmann <sven.eckelmann@gmx.de>
To: Tobias Klauser <tklauser@distanz.ch>
Cc: devel@driverdev.osuosl.org, b.a.t.m.a.n@lists.open-mesh.org,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Simon Wunderlich <siwu@hrz.tu-chemnitz.de>,
	Marek Lindner <lindner_marek@yahoo.de>
Subject: Re: [B.A.T.M.A.N.] [PATCH] staging: batman-adv: Use linux/etherdevice.h address helper functions
Date: Wed, 3 Nov 2010 11:56:19 +0100	[thread overview]
Message-ID: <201011031156.28683.sven.eckelmann@gmx.de> (raw)
In-Reply-To: <20101103102512.GD10579@distanz.ch>

[-- Attachment #1: Type: Text/Plain, Size: 2036 bytes --]

On Wednesday 03 November 2010 11:25:12 Tobias Klauser wrote:
> On 2010-11-03 at 11:12:12 +0100, Sven Eckelmann <sven.eckelmann@gmx.de> 
wrote:
> > On Wednesday 03 November 2010 10:59:02 you wrote:
> > > Replace custom ethernet address check functions by calls to the helpers
> > > in linux/etherdevice.h
> > 
> > Have you proven that the addresses are always two bytes aligned in
> > memory? Afaik this function needs it.
> 
> I don't think they need to be two bytes aligned, but I might be wrong.

compare_ether_addr uses a two byte pointer to access 3x two bytes. This makes 
it necessary to have all those 3 bytes aligned to 2 byte boundaries. Otherwise 
the compiler has to generate special instructions on architectures which don't 
support loads on non-aligned addresses. Usually he doesn't do it unless he has 
some indications that it is necessary (__attribute__ ((packed)) for example).

There is also documentation available on that topic in 
Documentation/unaligned-memory-access.txt

And maybe it is good to use is_broadcast_ether_addr, but leave 
compare_ether_addr part open (or prove that we always have those two operands 
correctly aligned).

> > > In one case where the address was tested for broadcast and multicast
> > > address, the broadcast address check can be omitted as broadcast is
> > > also a multicast address.
> > 
> > We need to distinguish between these two types for different
> > optimizations (research is currently done for multicast over mesh - but
> > currently not part of batman-adv).
> 
> I was refering to the following part of the patch:
> 
> -       if (is_bcast(ethhdr->h_dest) || is_mcast(ethhdr->h_dest)) {
> +       if (is_multicast_ether_addr(ethhdr->h_dest)) {
> 
> I think this change should be legitimate as the same branch is done for
> multicast and broadcast addresses.

Yes, in that situation it is correct. I was talking more about the complete 
bcast vs. multicast in batman-adv and didn't look at your patch.

Best regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2010-11-03 10:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-03  9:59 [B.A.T.M.A.N.] [PATCH] staging: batman-adv: Use linux/etherdevice.h address helper functions Tobias Klauser
2010-11-03 10:12 ` Sven Eckelmann
2010-11-03 10:25   ` Tobias Klauser
2010-11-03 10:56     ` Sven Eckelmann [this message]
2010-11-03 11:04       ` Sven Eckelmann
2010-11-03 12:00     ` Marek Lindner

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=201011031156.28683.sven.eckelmann@gmx.de \
    --to=sven.eckelmann@gmx.de \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@suse.de \
    --cc=lindner_marek@yahoo.de \
    --cc=siwu@hrz.tu-chemnitz.de \
    --cc=tklauser@distanz.ch \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.