From: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
To: Jean Delvare <jdelvare@suse.de>
Cc: Jay Vosburgh <fubar@us.ibm.com>, netdev@vger.kernel.org
Subject: Re: bonding with 3c59x driver
Date: Tue, 14 Feb 2012 11:35:02 +0100 [thread overview]
Message-ID: <20120214103502.GH32155@v3-1054> (raw)
In-Reply-To: <201202141122.10705.jdelvare@suse.de>
On Tue, Feb 14, 2012 at 11:22:10AM +0100, Jean Delvare wrote:
> Hi Jay,
>
> Thanks for the fast answer.
>
> On Monday 13 February 2012 11:13:11 pm Jay Vosburgh wrote:
> > Jean Delvare <jdelvare@suse.de> wrote:
> > >I am trying to do network bonding on top of 3com 3C905C ethernet
> > >adapters. I am facing the problem that network cable removal isn't
> > >detected. It is detected when using Realtek hardware with driver
> > > 8139too or VIA hardware with driver via-rhine, but no luck with
> > > driver 3c59x. I'm using bonding option miimon=100 for link
> > > detection.
> > >
> > >Does anyone know if this is a hardware limitation, or a missing
> > > feature of the 3c59x driver, or a bug in that driver?
> >
> > It just so happens that I was looking at 3c59x earlier today for
> > something else. It appears to run its internal link state detection
> > on a 5 second timer, after which (in theory) bonding's miimon would
> > notice (provided that the driver notices and calls
> > netif_carrier_off).
>
> Thanks for the pointer. There is indeed a 5 second timer to detect
> transitions from link down to link up. However the timer period to
> detect transitions from link up to link down is 1 minute. Knowing that,
> I tested again and indeed the bonding module end up detecting the link
> going down, after up to 1 minute. That's not exactly convenient for
> bonding.
>
> I admit I don't quite get the rationale for having different timer
> periods for detecting the link going up or down. Steffen, this was done
> by you in:
>
> commit b4ff6450f5336c492d1e2f184d3b8186e0716b7a
> Author: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
> Date: Sun Mar 26 01:37:40 2006 -0800
>
> [PATCH] 3c59x: decrease polling interval
>
> No rationale explained in the commit message. Can you explain? I find
> the asymmetry confusing, I'd rather use 5 seconds (if not less) for both
> cases.
This patch is based on a discussion with Andrew Morton some years ago.
The 3c59x does polling for external environment changes which is quite
expensive. Firing a timer that disables the interrupts on a running
interface every 5 seconds is just not reasonable for checking for external
environment changes. So we decided to let it depend on the link status,
5 seconds if the link is down and 60 seconds if the link is up.
next prev parent reply other threads:[~2012-02-14 10:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-13 21:53 bonding with 3c59x driver Jean Delvare
2012-02-13 22:13 ` Jay Vosburgh
2012-02-14 10:22 ` Jean Delvare
2012-02-14 10:35 ` Steffen Klassert [this message]
2012-02-14 10:44 ` David Laight
2012-02-14 11:06 ` Steffen Klassert
2012-02-14 11:13 ` Eric Dumazet
2012-02-14 12:50 ` Jean Delvare
2012-02-14 13:34 ` Steffen Klassert
2012-02-14 19:43 ` David Miller
2012-02-14 20:27 ` [PATCH] 3c59x: shorten timer period for slave devices Eric Dumazet
2012-02-14 20:51 ` Dan Williams
2012-02-14 21:02 ` Eric Dumazet
2012-02-14 21:28 ` David Miller
2012-02-14 18:27 ` bonding with 3c59x driver Rick Jones
2012-02-14 19:27 ` Jean Delvare
2012-02-14 21:06 ` Chris Friesen
2012-02-15 9:53 ` Jean Delvare
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=20120214103502.GH32155@v3-1054 \
--to=klassert@mathematik.tu-chemnitz.de \
--cc=fubar@us.ibm.com \
--cc=jdelvare@suse.de \
--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