Subject: Re: bonding directly changes underlying device address

From: Or Gerlitz <[email-masked]>
Date: Wed, 14 May 2014 11:08:41 +0300

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.