netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jay Vosburgh <fubar@us.ibm.com>
To: Jesper Krogh <jesper@krogh.cc>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jeff Garzik <jgarzik@redhat.com>,
	aowi@novozymes.com
Subject: Re: Regression in bonding between 2.6.26.8 and 2.6.27.6 - bisected
Date: Fri, 27 Feb 2009 08:28:39 -0800	[thread overview]
Message-ID: <16084.1235752119@death.nxdomain.ibm.com> (raw)
In-Reply-To: <49A7B17F.2020408@krogh.cc>

Jesper Krogh <jesper@krogh.cc> wrote:
[...]
>The offending commit seems to be:
>
>bonding: refactor mii monitor
>
>Refactor mii monitor.  As with the previous ARP monitor refactor,
>the motivation for this is to handle locking rationally (in this case,
>removing conditional locking) and generally clean up the code.
>
>This patch breaks up the monolithic mii monitor into two phases:
>an inspection phase, followed by an optional commit phase.  The commit phase
>is the only portion that requires RTNL or makes changes to state, and is
>only called when inspection finds something to change.
>
>Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
>Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
>
>
>A test with a fresh 2.6.29-rc6 revealed that the problem has been fixed
>subsequently.. but still exists in 2.6.27-newest.  (havent tested
>2.6.28-newest yet).
>
>Any ideas of what the "fixing" commit is .. or should that also be
>bisected?

	I went back and looked at your earlier mail.  Since you're using
802.3ad mode, my first guess would be this commit:

commit fd989c83325cb34795bc4d4aa6b13c06f90eac99
Author: Jay Vosburgh <fubar@us.ibm.com>
Date:   Tue Nov 4 17:51:16 2008 -0800

    bonding: alternate agg selection policies for 802.3ad
    
        This patch implements alternative aggregator selection policies
    for 802.3ad.  The existing policy, now termed "stable," selects the active
    aggregator by greatest bandwidth, and only reselects a new aggregator
    if the active aggregator is entirely disabled (no more ports or all ports
    down).
    
        This patch adds two new policies: bandwidth and count, selecting
    the active aggregator by total bandwidth (like the stable policy) or by
    the number of ports in the aggregator, respectively.  These two policies
    also differ from the stable policy in that they will reselect the active
    aggregator when availability-related changes occur in the bond (e.g.,
    link state change).
    
        This permits "gang failover" within 802.3ad, allowing redundant
    aggregators along parallel paths to always maintain the "best" aggregator
    as the active aggregator (rather than having to wait for the active to
    entirely fail).
    
        This patch also updates the driver version to 3.5.0.
    
    Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>


	This changed or refactored a great deal of the aggregator
selection logic, and it might be that it also fixed your problem by mere
happenstance.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

  reply	other threads:[~2009-02-27 16:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-16  9:41 Regression in bonding between 2.6.26.8 and 2.6.27.6 Jesper Krogh
2008-11-17 23:45 ` Jay Vosburgh
2008-11-18 20:24   ` Jesper Krogh
2008-11-18 20:28     ` Jesper Krogh
2008-11-18 20:53     ` Jay Vosburgh
2008-11-19  7:53       ` Jesper Krogh
2008-12-08 20:42     ` Brandeburg, Jesse
2008-11-19 10:01   ` Jesper Krogh
2009-02-27  9:25 ` Regression in bonding between 2.6.26.8 and 2.6.27.6 - bisected Jesper Krogh
2009-02-27 16:28   ` Jay Vosburgh [this message]
2009-02-27 20:07     ` Jesper Krogh
2009-02-27 20:35       ` Jay Vosburgh
2009-02-28 17:21         ` Jesper Krogh
2009-03-01  6:21         ` Jesper Krogh
2009-03-01 13:19           ` Regression in bonding between 2.6.26.8 and 2.6.27.6 - bisected - twice Jesper Krogh
2009-03-05 18:51             ` Jay Vosburgh
2009-03-09 20:53               ` Jesper Krogh
2009-03-13 23:12                 ` David Miller
2009-03-13 23:27                   ` Jay Vosburgh
2009-03-16 20:34                     ` Jesper Krogh
2009-03-16 20:35                       ` David Miller
2009-03-17 20:18                         ` Jesper Krogh
2009-03-19  1:39                     ` David Miller

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=16084.1235752119@death.nxdomain.ibm.com \
    --to=fubar@us.ibm.com \
    --cc=aowi@novozymes.com \
    --cc=jesper@krogh.cc \
    --cc=jgarzik@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).