Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753721Ab2KTBDJ (ORCPT ); Mon, 19 Nov 2012 20:03:09 -0500 Received: from e5.ny.us.ibm.com ([32.97.182.145]:54079 "EHLO e5.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753486Ab2KTBDI (ORCPT ); Mon, 19 Nov 2012 20:03:08 -0500 From: Jay Vosburgh To: Zheng Li cc: netdev@vger.kernel.org, andy@greyhouse.net, linux-kernel@vger.kernel.org, davem@davemloft.net, joe.jin@oracle.com Subject: Re: [PATCH] bonding: rlb mode of bond should not alter ARP originating via bridge In-reply-to: <1352972861-17577-1-git-send-email-zheng.x.li@oracle.com> References: <1352972861-17577-1-git-send-email-zheng.x.li@oracle.com> Comments: In-reply-to Zheng Li message dated "Thu, 15 Nov 2012 17:47:41 +0800." X-Mailer: MH-E 8.2; nmh 1.4; GNU Emacs 23.4.1 Date: Mon, 19 Nov 2012 17:02:34 -0800 Message-ID: <30871.1353373354@death.nxdomain> X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12112001-5930-0000-0000-00000E4F673B Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4067 Lines: 116 Zheng Li wrote: >ARP traffic passing through a bridge and out via the bond (when the bond is a >port of the bridge) should not have its source MAC address adjusted by the >receive load balance code in rlb_arp_xmit. This patch differs from prior versions in that it does more than what's described here; it also disables the receive load balance logic for any ARPs (request or reply) that are passing through the bond (not of local origin). For ARP replies, that's mostly harmless, as the ARPs passing through will simply always be sent from one particular slave (the active slave) instead of being balanced. For ARP requests, though, they are already always sent via the active slave, but there is also some logic in rlb_arp_xmit to limit the side effects from the broadcast ARP, in particular this part: /* The ARP reply packets must be delayed so that * they can cancel out the influence of the ARP request. */ bond->alb_info.rlb_update_delay_counter = RLB_UPDATE_DELAY; /* arp requests are broadcast and are sent on the primary * the arp request will collapse all clients on the subnet to * the primary slave. We must register these clients to be * updated with their assigned mac. */ rlb_req_update_subnet_clients(bond, arp->ip_src); that arranges for clients to be given ARP updates for their slave assignments (which may change to the active slave, due to the ARP broadcast being sent via the active slave). I think the ARP reply side of this is fine (and is what is described in teh changelog), but the ARP request behavior change is new with this version. Since prior versions of the patch didn't cause this code to be skipped, is this change intentional? Did you check to see if the above logic is necessary for ARP requests passing through via a bridge to prevent peers from "stacking" (in terms of load balance assignment) on the active slave due to bridged ARP traffic? -J >Signed-off-by: Zheng Li >Cc: Jay Vosburgh >Cc: Andy Gospodarek >Cc: "David S. Miller" > >--- > drivers/net/bonding/bond_alb.c | 6 ++++++ > drivers/net/bonding/bonding.h | 13 +++++++++++++ > 2 files changed, 19 insertions(+), 0 deletions(-) > >diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c >index e15cc11..75f6f0d 100644 >--- a/drivers/net/bonding/bond_alb.c >+++ b/drivers/net/bonding/bond_alb.c >@@ -694,6 +694,12 @@ static struct slave *rlb_arp_xmit(struct sk_buff *skb, struct bonding *bond) > struct arp_pkt *arp = arp_pkt(skb); > struct slave *tx_slave = NULL; > >+ /* Only modify ARP's MAC if it originates locally; >+ * don't change ARPs arriving via a bridge. >+ */ >+ if (!bond_slave_has_mac(bond, arp->mac_src)) >+ return NULL; >+ > if (arp->op_code == htons(ARPOP_REPLY)) { > /* the arp must be sent on the selected > * rx channel >diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h >index f8af2fc..6dded56 100644 >--- a/drivers/net/bonding/bonding.h >+++ b/drivers/net/bonding/bonding.h >@@ -22,6 +22,7 @@ > #include > #include > #include >+#include > #include "bond_3ad.h" > #include "bond_alb.h" > >@@ -450,6 +451,18 @@ static inline void bond_destroy_proc_dir(struct bond_net *bn) > } > #endif > >+static inline struct slave *bond_slave_has_mac(struct bonding *bond, >+ const u8 *mac) >+{ >+ int i = 0; >+ struct slave *tmp; >+ >+ bond_for_each_slave(bond, tmp, i) >+ if (ether_addr_equal_64bits(mac, tmp->dev->dev_addr)) >+ return tmp; >+ >+ return NULL; >+} > > /* exported from bond_main.c */ > extern int bond_net_id; >-- >1.7.6.5 --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/