All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Toppins <jtoppins@redhat.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Jay Vosburgh <jay.vosburgh@canonical.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Veaceslav Falico <vfalico@gmail.com>,
	Andy Gospodarek <andy@greyhouse.net>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: bonding: link state question
Date: Sun, 8 Aug 2021 21:31:39 -0400	[thread overview]
Message-ID: <79019b7e-1c2e-7186-4908-cf085b33fb59@redhat.com> (raw)
In-Reply-To: <20210808044912.GA10092@1wt.eu>

On 8/8/21 12:49 AM, Willy Tarreau wrote:
> On Sat, Aug 07, 2021 at 08:09:31PM -0400, Jonathan Toppins wrote:
>> setting miimon = 100 does appear to fix it.
>>
>> It is interesting that there is no link monitor on by default. For example
>> when I enslave enp0s31f6 to a new bond with miimon == 0, enp0s31f6 starts
>> admin down and will never de-assert NO-CARRIER the bond always results in an
>> operstate of up. It seems like miimon = 100 should be the default since some
>> modes cannot use arpmon.
> 
> Historically when miimon was implemented, not all NICs nor drivers had
> support for link state checking at all! In addition, there are certain
> deployments where you could rely on many devices by having a bond device
> on top of a vlan or similar device, and where monitoring could cost a
> lot of resources and you'd prefer to rely on external monitoring to set
> all of them up or down at once.
> 
> I do think however that there remains a case with a missing state
> transition in the driver: on my laptop I have a bond interface attached
> to eth0, and I noticed that if I suspend the laptop with the link up,
> when I wake it up with no interface connected, the bond will not turn
> down, regardless of miimon. I have not looked closer yet, but I
> suspect that we're relying too much on a state change between previous
> and current and that one historically impossible transition does not
> exist there and/or used to work because it was handled as part of
> another change. I'll eventually have a look.
> 
> Willy
> 

I am likely very wrong but the lack of a recalculation of the bond 
carrier state after a lower notifies of an up/down event seemed 
incorrect. Maybe a place to start?

diff --git i/drivers/net/bonding/bond_main.c 
w/drivers/net/bonding/bond_main.c
index 9018fcc59f78..2b2c4b937142 100644
--- i/drivers/net/bonding/bond_main.c
+++ w/drivers/net/bonding/bond_main.c
@@ -3308,6 +3308,7 @@ static int bond_slave_netdev_event(unsigned long 
event,
                  */
                 if (bond_mode_can_use_xmit_hash(bond))
                         bond_update_slave_arr(bond, NULL);
+               bond_set_carrier(bond);
                 break;
         case NETDEV_CHANGEMTU:
                 /* TODO: Should slaves be allowed to


  reply	other threads:[~2021-08-09  1:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-07 21:26 bonding: link state question Jonathan Toppins
2021-08-07 22:42 ` Jay Vosburgh
2021-08-08  0:09   ` Jonathan Toppins
2021-08-08  4:49     ` Willy Tarreau
2021-08-09  1:31       ` Jonathan Toppins [this message]
2021-08-09 10:10         ` Willy Tarreau

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=79019b7e-1c2e-7186-4908-cf085b33fb59@redhat.com \
    --to=jtoppins@redhat.com \
    --cc=andy@greyhouse.net \
    --cc=davem@davemloft.net \
    --cc=jay.vosburgh@canonical.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vfalico@gmail.com \
    --cc=w@1wt.eu \
    /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.