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

[Jarod Wilson <jarod@redhat.com>]

On 2017-04-05 9:45 PM, David Miller wrote:
> From: Jarod Wilson <jarod@redhat.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@redhat.com