From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ding Tianhong Subject: Re: [PATCH net-next] bonding: lacp_port_id setting for 802.3ad Date: Wed, 14 Aug 2013 09:46:19 +0800 Message-ID: <520AE16B.3040705@huawei.com> References: <5208C4BA.9020605@ivancso.net> <520986DC.4030805@huawei.com> <5209FA49.6030800@ivancso.net> <5209FEBC.4050305@huawei.com> <520A11CD.8060400@ivancso.net> <19765.1376418334@death.nxdomain> <520AC296.2080503@ivancso.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Jay Vosburgh , To: Krisztian Ivancso Return-path: Received: from szxga03-in.huawei.com ([119.145.14.66]:42418 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758814Ab3HNBrL (ORCPT ); Tue, 13 Aug 2013 21:47:11 -0400 In-Reply-To: <520AC296.2080503@ivancso.net> Sender: netdev-owner@vger.kernel.org List-ID: On 2013/8/14 7:34, Krisztian Ivancso wrote: > On 08/13/2013 08:25 PM, Jay Vosburgh wrote: >> Krisztian Ivancso wrote: >> >>> On 08/13/2013 11:39 AM, Ding Tianhong wrote: >>>> On 2013/8/13 17:20, Krisztian Ivancso wrote: >>>>> On 08/13/2013 03:07 AM, Ding Tianhong wrote: >>>>>> On 2013/8/12 19:19, Krisztian Ivancso wrote: >>>>>>> >From 472fffa5a8f170daed9e4cc677af8e2560b86be2 Mon Sep 17 00:00:00 2001 >>>>>>> From: Krisztian Ivancso >>>>>>> Date: Sun, 11 Aug 2013 20:30:44 +0200 >>>>>>> Subject: [PATCH net-next] bonding: lacp_port_id setting for 802.3ad ports >>>> >>>> ok, for example: the bonding has four slave, slave1 and slave2 aggregation to 1 group, >>>> and slave3 and slave4 aggregtion to 2 group, how you distinguish the 1 and 2 group by initialize id. >>> >>> this is not possible, because all slave have to be a member of the same >>> aggregation group. >> >> Just on the above point, bonding can group slaves into multiple >> aggregators, but only one aggregator will be active at any given time. >> >> To answer the question, the four slaves would each be given >> unique port IDs that do not conflict. >> >>> i think we misunderstood each other. >>> >>> here is a new example: >>> - switch1 is a switch with a configured lag with two members ports >>> (member1 and member2) >>> - two linux (linux1 and linux2) box with a configured bonding device >>> (bond0) with the same MAC set in both box and one >>> slave on each >>> - lacp_port_id is set to 10 in linux1 and 20 in linux2 >>> >>> you can attach the slave from both linux boxes to the same >>> lag on switch1. (slave from linux1 to port member1 and >>> slave from linux2 to port member2 on switch1) >>> >>> port id must be unique within a system. >>> bonding implementation set a unique system id for every bonding device >>> which is derived from MAC of one of the slave interfaces. >>> >>> if we use the current bonding implementation second linux box can't be >>> a member on switch1 because port id is 1 in both linux bonding device. >>> >>> if we can set different starting port id for bonding in different boxes >>> the second box can be a member also. >> >> I understand what you're trying to do here (permit multiple >> instances of bonding on different systems to connect to a single >> aggregator on a switch), and I don't really have a problem with it in >> general. >> >> I do have some comments: >> >> First, altering the lacp_port_id (via sysfs) should only be >> permitted when there are no slaves in the bond, otherwise the >> /proc/net/bonding/bond0 output for the first port id will not match the >> actual first port id value assigned to the slaves. As a practical >> matter, altering lacp_port_id while slaves are present in the bond has >> no effect until all slaves are released and the first new slave is >> added, so this is not reducing functionality. >> >> Second, the lacp_port_id is global across all bonds created >> within the loaded module, and so multiple bonds will all use the same >> starting value. Setting the lacp_port_id via sysfs has no effect, as it >> alters a per-bond value, bond->params.lacp_port_id, that is never >> actually used to set the port ID of a first slave in bond_enslave. >> >> The global default value should only be used to initialize the >> per-bond value when a bond is created, and that per-bond value should be >> used when setting the port id in bond_enslave(). The per-bond value is >> already displayed in /proc/net/bonding/bond0, and is the value modified >> by the sysfs functions >> >> Third, consider adding the port ID to the 803.2ad section in >> bond_info_show_slave. > > Thanks for these great comments. I'll soon fix sysfs related bug and > rework patch. > >> >> Lastly, I think this should be tested against systems other than >> Cisco to insure that it really interoperates with, for example, >> Juniper's methodology for spanning an aggregator across physical >> chassis. I'm not sure why it wouldn't, but once new functionality >> becomes part of the kernel, changing it in non-backwards compatible ways >> is difficult. > agreed Ding Tianhong > I agree. I try to test it with devices from other manufacturers. > > > . >