On Sun, 2 Jul 2000, Andrew Morton wrote:
> What's the story on MAC-level flow control?
>
> The only Linux drivers I can find which do this are Donald's latest
> eepro100 and 3com's 3c90x. starfire seems to have infrastructure but
> never turns it on.
Some updated chips that have added flow control and have on-chip
transceivers look at the negotiation results and turn on flow control
without driver intervention. So you don't see explicit driver support.
This is good for me because it's not always clear which chip revision had
flow control added.
Surprisingly, flow control has had a major impact on driver Rx structure.
Most designs automatically trigger flow control when the chip is about to
run out of Rx buffers. My drivers used to be structured to never run out of
Rx buffers to avoid this case -- they recycled Rx buffers rather than
passing them to the software queue layer when they were running short.
So I changed the drivers to run out of Rx buffers(!) when the system
(usually the slow skbuff allocation routine) couldn't keep up with traffic.
Note the discussion last week on the netdev mailing list about changing this
back. People don't understand that was the behavior the drivers used to
have, and it was explicitly changed for this reason. You have to understand
the Big Picture.
Note that you cannot fake flow control with driver software. The Rx pause
frames must be put at the very front of the transmit queue, and you have to
handle Tx resume frames even if you have no Rx buffers lest you end up
deadlocked.
> Is this considered a useful thing to have?
> This abstract:
> http://www.computer.org/proceedings/lcn/0309/03090160abs.htm makes it
> sound bad.
When reading papers list this you should be aware of an "ATM bias". There
are people that claim "if it doesn't have the functionality that ATM
promised, it's not worth doing".
When ATM was introduced, it claimed end-to-end flow control and reserved
bandwidth. It took many years of additional development and dramatically
more hardware and software than was initially claimed before this could even
be demoed. Even today a multi-vendor ATM network might not fulfill a
bandwidth reservation.
Ethernet flow control is a good feature to have in a typical LAN with
bursty traffic and a mix of device speeds. It doesn't help, and likely
hurts, when you have saturating (e.g. streaming multimedia) traffic.
Ethernet flow control certainly shouldn't be used to do end-to-end traffic
flow control. Think of it like electrical power wiring. It's much less
complicated to install thicker wiring than to have a complicated system that
switches off the neighbor's water heater when you turn on your microwave.
Ethernet flow control is like a circuit breaker that trips when you plug too
many lamps into the same outlet,
> This article: http://www.nwfusion.com/netresources/0913flow.html and the
> vendor opinions at http://www.nwfusion.com/netresources/0913flow2.html
> show mixed opinions.
That's good coverage of the issues, biased by some vendor justification for
their approach.
> I would have thought that if a switch is doing 10<->100 conversion then
> it would be a good thing to have for non-TCP protocols (eg, streaming
> media across the LAN, NFS).
Simple streaming is where flow control can fall down. If you have bursty
traffic on top of 50% or less streaming traffic, then flow control can work
great.
Donald Becker becker@xxxxxxxxx
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Beowulf Clusters / Linux Installations
Annapolis MD 21403
|