[Top] [All Lists]

RE: [PATCH] (3/4) bridge linkstate handling

To: <hadi@xxxxxxxxxx>, "Stephen Hemminger" <shemminger@xxxxxxxx>
Subject: RE: [PATCH] (3/4) bridge linkstate handling
From: "Eble, Dan" <DanE@xxxxxxxxxx>
Date: Thu, 29 Jul 2004 09:24:53 -0400
Cc: <bridge@xxxxxxxx>, <netdev@xxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
Thread-index: AcR1ZWR6/dWjVsnZQqSw9QfJJKX7mgABwyZQ
Thread-topic: [PATCH] (3/4) bridge linkstate handling
> > This makes bridge port status reflect both the
> > state of the interface from software (up/down)
> > and the carrier.  It makes STP handle link failure
> > (cable breakage, etc).
> nice. Does this entrench STP further in the kernel?
> Still planning to move it out to user space?

Even if STP were implemented in user space, this part should be done in
the kernel to make sure that there is no window of time for a packet to
be received or transmitted after the link state changes.  Cable failure
is not the worst problem here.  Imagine some dunce pulling out a cable,
realizing he pulled the wrong one, and then plugging it back into the
wrong port.  If he has created a loop in the network, even a single
packet getting through can cause problems.

One could be really paranoid and flush the hardware transmit queue too.
Is there a way to do that for a port from the bridge driver?  (Or should
the device drivers do that anyway after a link change?)

Are there any ethernet controllers that can automatically disable tx/rx
after a link change, requiring the driver to reenable them?  That would
also be useful.

<Prev in Thread] Current Thread [Next in Thread>