From: WeipingPan <panweiping3@gmail.com>
To: Eduard Sinelnikov <eduard.sinelnikov@gmail.com>
Cc: netdev@vger.kernel.org, Andy Gospodarek <andy@greyhouse.net>,
Jay Vosburgh <fubar@us.ibm.com>
Subject: Re: Bonding problem
Date: Mon, 15 Aug 2011 18:22:45 +0800 [thread overview]
Message-ID: <4E48F375.7000504@gmail.com> (raw)
In-Reply-To: <CANMAZFWYUqDDp+_9EOOubRcvC90zHO9NR7D_N5D=uTjokpgU6A@mail.gmail.com>
On 08/15/2011 05:44 PM, Eduard Sinelnikov wrote:
> Hi all,
>
> Following the thread:
> http://marc.info/?l=linux-netdev&m=131282467512508&w=2
>
> I have created the this patch for kernel version:3.0.1, which may fix
> the bonding problem
>
> Patch explanation:
> The patch seting all slaves active prior to switching to round robin mode.
> This is done to ensure that every posibly active slave will be used in
> communication.
>
> Also, I noticed that just changing the bond_xmit_round_robin will only
> partially fix the problem.
> Since slaves with inactive bit will not CATCH any trafic.
>
> I wonder if I should remove the check "bond_is_active_slave(slave))"
> in bond_xmit_round_robin
>
> Please advice.
> Eduard
>
>
My patch is to restore the backup and inactive flag of slave, too,
and I think it is more generic. :-)
Will send it soon.
thanks
Weiping Pan
> On Mon, Aug 08, 2011 at 10:06:05AM -0700, Jay Vosburgh wrote:
>> Andy Gospodarek<andy@greyhouse.net> wrote:
>>
>>> On Sun, Aug 07, 2011 at 03:00:30PM +0300, Eduard Sinelnikov wrote:
>>>> Hi,
>>>>
>>>> In the kernel 2.6.39.3 ( /drivers/net/bond/bond_main.c).
>>>> In the function  ‘bond_xmit_roundrobin’
>>>> The code check if the bond is active via
>>>> ‘bond_is_active_slave(slave)’ Function call.
>>>> Which actually checks if the slave is backup or active
>>>> What is the meaning of slave being  backup in round robin mode?
>>>> Correct me if I wrong but in round robin every slave should send a
>>>> packet, regardless of being active or backup.
>>>>
>>>> Thank you,
>>>> Â Â Â Â Â Â Eduard
>>> There probably is not a compelling reason to continue to have it. There
>>> may be a reason historically, but I'm not aware what that might be at
>>> this point. For modes other than active-backup, the value of
>>> slave->link and slave->backup should always contain a value that
>>> indicates the slave is up and available for transmit.
>> If you read Eduard's other posts regarding this, the actual
>> issue is that when changing from another mode into round-robin,
>> occasionally slaves will still be marked as "backup" and won't be used:
>>
> I did notice that one after I sent this first response.
>
>>> Date: Mon, 8 Aug 2011 11:16:39 +0300
>>> Subject: On line Bonding configuration change fails
>>> From: Eduard Sinelnikov<eduard.sinelnikov@gmail.com>
>>> To: netdev@vger.kernel.org
>>> Sender: netdev-owner@vger.kernel.org
>>>
>>> Hi,
>>>
>>> My configuration is a follows:
>>>
>>> Â Â Â Â Â Â Â | eth0 -------------->
>>> Ububntu | eth1 --------------> Â Â Swith ------------> Other computer
>>>
>>> Scenario:
>>> • change the bond mode to active/backup
>>> • unplug some of the cable
>>> • plug-in the unplugged cable
>>> • change bond mode to round robin
>>>
>>> I can see that only one eth1 is sending data. When I unplug it the ping stops.
>>>
>>> Is it a bug or some mis-configuration?
>>>
>>> In the kernel ( /drivers/net/bond/bond_main.c).
>>> In the function  ‘bond_xmit_roundrobin
>>> ’
>>> The code check if the bond is active via
>>> ‘bond_is_active_slave(slave)’ Function call.
>>> Which actually checks if the slave is backup or active
>>> What is the meaning of backup in round robin?
>>> Correct me if I wrong but in round robin every slave should send a
>>> packet, regardless of being active or backup.
>> So from looking at the code, it seems that the actual problem is
>> that when transitioning to round-robin mode, one or more slaves can
>> remain marked as "backup," and in round-robin mode, that won't ever
>> change. We could probably work around that by removing the "is_active"
>> test (essentially declaring that "is_active" is only valid in
>> active-backup mode). That might produce a few odd messages here and
>> there (when removing a slave or during a link failure, for example).
>>
>> From inspection, the bond_xmit_xor function likely has this same
>> problem.
>>
> Agreed.
>
>> -J
>>
>> ---
>> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
next prev parent reply other threads:[~2011-08-15 10:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-15 9:44 Bonding problem Eduard Sinelnikov
2011-08-15 10:22 ` WeipingPan [this message]
2011-08-15 10:25 ` [PATCH net-2.6] bonding:restore backup and inactive flag of slave Weiping Pan
2011-08-15 16:18 ` WANG Cong
2011-08-16 1:57 ` [PATCH net-2.6 V2] bonding:reset " Weiping Pan
2011-08-16 12:30 ` WANG Cong
2011-08-18 3:12 ` David Miller
-- strict thread matches above, loose matches on Subject: below --
2011-08-07 12:00 Bonding problem Eduard Sinelnikov
2011-08-08 16:26 ` Andy Gospodarek
2011-08-08 17:06 ` Jay Vosburgh
2011-08-08 17:31 ` Andy Gospodarek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E48F375.7000504@gmail.com \
--to=panweiping3@gmail.com \
--cc=andy@greyhouse.net \
--cc=eduard.sinelnikov@gmail.com \
--cc=fubar@us.ibm.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.