All of lore.kernel.org
 help / color / mirror / Atom feed
From: Or Gerlitz <ogerlitz@mellanox.com>
To: Veaceslav Falico <vfalico@gmail.com>,
	Jay Vosburgh <jay.vosburgh@canonical.com>
Cc: Or Gerlitz <or.gerlitz@gmail.com>, Jiri Pirko <jiri@resnulli.us>,
	"Eyal Perry" <eyalpe@mellanox.com>,
	netdev <netdev@vger.kernel.org>,
	Noa Osherovich <noaos@mellanox.com>
Subject: Re: bonding directly changes underlying device address
Date: Wed, 14 May 2014 11:08:41 +0300	[thread overview]
Message-ID: <53732489.3070204@mellanox.com> (raw)
In-Reply-To: <20140514080114.GA30960@mikrodark.usersys.redhat.com>

On 14/05/2014 11:01, Veaceslav Falico wrote:
>
> I'd actually just drop support for non-ndo_set_mac_address NICs, as it'll
> unify the RLB and TLB logic, and anyways dev_set_mac_address() is used in
> SIOCSIFHWADDR and rtnl ops, and thus, if the NIC doesn't support it, it
> can't change its mac address at all, and using it in *LB modes makes 
> little sense.

Avoid touching the slave device address directly and acting through 
dev_set_mac_address() sounds good to me.

Still, FWIW && just to make sure we see the whole picture, we noted that 
the practiceof manually touching the slave device address is done in 
another TLB code locationbesides alb_set_slave_mac_addr(), namely in 
alb_set_mac_address().

>
> Other way of doing this would be to just move the dev_addr to the slave
> struct, instead of using the net_device's dev_addr, cause in tlb we don't
> usually need to set the NIC mac address (except when there's mac 
> filtering,
> I guess), but only need to set the packet's source mac. This way we'll 
> omit
> quite costy mac address setting (as, on some NICs, it resets the whole 
> NIC
> and takes seconds), still maintain compatibility with older NICs and 
> won't
> mess with NICs ->dev_addr.

Interesting, so if Jay is OK with this design, any chance one of you can 
come up
with the proper patch to make that happen?

Or.

  reply	other threads:[~2014-05-14  8:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-13 11:06 bonding directly changes underlying device address Or Gerlitz
2014-05-13 11:55 ` Jiri Pirko
2014-05-13 16:30   ` Jay Vosburgh
2014-05-13 17:38     ` Or Gerlitz
2014-05-14  8:01       ` Veaceslav Falico
2014-05-14  8:08         ` Or Gerlitz [this message]
2014-05-15  1:38         ` Jay Vosburgh
2014-05-15  4:55           ` Veaceslav Falico
2014-05-15 12:37             ` Or Gerlitz

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=53732489.3070204@mellanox.com \
    --to=ogerlitz@mellanox.com \
    --cc=eyalpe@mellanox.com \
    --cc=jay.vosburgh@canonical.com \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=noaos@mellanox.com \
    --cc=or.gerlitz@gmail.com \
    --cc=vfalico@gmail.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 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.