From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756139AbdDFSBP (ORCPT ); Thu, 6 Apr 2017 14:01:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55916 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753506AbdDFSBJ (ORCPT ); Thu, 6 Apr 2017 14:01:09 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8624D65D0A Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jarod@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 8624D65D0A Subject: Re: [PATCH net-next] bonding: attempt to better support longer hw addresses To: David Miller Cc: linux-kernel@vger.kernel.org, j.vosburgh@gmail.com, vfalico@gmail.com, andy@greyhouse.net, netdev@vger.kernel.org References: <20170404213242.50079-1-jarod@redhat.com> <20170405.184554.1608171595937690317.davem@davemloft.net> From: Jarod Wilson Message-ID: Date: Thu, 6 Apr 2017 14:01:06 -0400 User-Agent: Mutt/1.5.21 (2010-09-15) MIME-Version: 1.0 In-Reply-To: <20170405.184554.1608171595937690317.davem@davemloft.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 06 Apr 2017 18:01:08 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017-04-05 9:45 PM, David Miller wrote: > From: Jarod Wilson > 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