netdev - Re: [PATCH net-next] bonding: attempt to better support longer hw addresses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <fd21e0a4-0bd9-f07f-7204-2a95845dae38@redhat.com>
Date:   Thu, 6 Apr 2017 14:01:06 -0400
From:   Jarod Wilson <jarod@...hat.com>
To:     David Miller <davem@...emloft.net>
Cc:     linux-kernel@...r.kernel.org, j.vosburgh@...il.com,
        vfalico@...il.com, andy@...yhouse.net, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] bonding: attempt to better support longer hw
 addresses

On 2017-04-05 9:45 PM, David Miller wrote:
> From: Jarod Wilson <jarod@...hat.com>
> Date: Tue,  4 Apr 2017 17:32:42 -0400
...
> Applied, but:
> 
>> +static inline void bond_hw_addr_copy(u8 *dst, const u8 *src, unsigned int len)
>> +{
>> +	if (len == ETH_ALEN) {
>> +		ether_addr_copy(dst, src);
>> +		return;
>> +	}
>> +
>> +	memcpy(dst, src, len);
>> +}
> 
> I wonder how much value there is in trying to conditionally use
> ether_addr_copy().  Unless some of these calls are in the data
> plane, just a straight memcpy() all the time is fine and much
> simpler.

Yeah, I wasn't sure how much gain the bonding driver actually got from 
using the super-optimized ether_addr_copy(), and thought about just 
doing a memcpy all the time, but wanted to go for minimal impact to 
traditional ethernet bonding. Looks like bond_handle_frame() might 
benefit from sticking to ether_addr_copy() when it can, but the majority 
of other callers, at least in bond_main.c, are all in setup, teardown 
and failover paths, which ought to be tolerant of some overhead, though 
optimized failover isn't a bad thing for connection uptime. I do see 
bond_alb.c has one caller in the arp transmit path as well. I think I'm 
inclined to just leave well enough alone for the moment.

-- 
Jarod Wilson
jarod@...hat.com