Jay Vosburgh wrote:
Or Gerlitz <[EMAIL PROTECTED]> wrote:
I'll just note that all of the bonding parameters and such are
documented in the Documentation/networking/bonding.txt file that comes
with the kernel source code. You can also download the documentation
from sourceforge.net/projects/bonding.
Just to be clear, i have looked in Documentation/networking/bonding.txt
before sending this question.
To answer your question, you'd have to specify an miimon=X
interval (where X is some nonzero value, e.g., 100). The default for
the use_carrier parameter is 1, which is what you want, so there is no
need to specify it. The purpose of the use_carrier parameter is to
permit the old method to be used for network drivers that don't support
netif_carrier (which are pretty rare these days).
With old method you refer to the bonding driver using MII ioctls etc vs
just calling netif_carrier_ok().
>What i want to better understand here, is whether for the bonding driver
>to declare a slave as "being able to carry traffic" it assumes the slave
>will move from UP to RUNNING state (and later netif_carrier_ok would
>return TRUE) without an IP address being set for the slave device ???
The RUNNING state is set (indirectly) by the device driver when
it calls netif_carrier_on(); this is totally unrelated to the IP address
information attached to an interface. Whatever IP address is set for a
slave is not used during operation.
OK, thanks for clarifying this.
>Is (per the bonding driver) the **time** it should take the slave to get
>from UP to (RUNNING && carrier_ok) state limited and/or controlled?
I'm not exactly sure what you're asking here, but when miimon is
enabled, if the slave is not netif_carrier_ok() during any of the
periodic checks, it will be disabled by the bonding driver.
The transition from being UP to having carrier might involve third party
and hence take some time (eg in IP over Infiniband the broadcast traffic
is carried over a dedicated IB multicast group and joining this group is
carried by communication with the Infiniband SA). But if the bonding
code does periodic checks, this is fine.
There are also updelay and downdelay parameters to handle cases
where it takes some amount of real time for a carrier state transition
to occur (and, thus, state changes should be ignored for a period of
time). E.g., some switches will assert link up on a port before they
are actually able to send and receive traffic; in that case, bonding
could use the updelay parameter to ignore link up changes for a period
of time.
OK understood.
Or.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
