[vortex] 3c905C: Packet losses (a more precise description)

[Donald Becker]

On Thu, 6 Jul 2000, Andrew Morton wrote:

> > Errrmm, no, that's not right either.
> > You should never force-on flow control unless you are in full duplex mode.
> 
> Yup.  This was just a "suck it and see" experiment...
> 
> > And you really shouldn't enable flow control when you haven't negotiated
> > it.  Otherwise you might stop transmitting when someone sends network-wide
> > flow control packets.
> 
> Not sure I understand that.  If someone sends a network-wide PAUSE, they
> presumably want you to pause??

No!  Bad Bad Bad

Imagine a broken or evil host on a network sends a flow control packet.
They look like regular multicast packets, so they are propaged everywhere.
Everyone stops transmi_________tting.

> When I put flow control support into the 2.4 driver I decided to ignore
> the partner's capabilities and rely upon the user knowing what he is
> doing.  So if you give the 'flow_ctrl=1' module option, it's simply
> enabled (if full duplex).  I guess I should have examined partner
> capabilities as well.

How many forced-full-duplex bogus bug reports do you think I get a day?
I would drop the full_duplex flag instantly if I though I could get away
with it, but I would get even more emails bitching about it.

You just gratuitously added a flag that can cause nearly as bad of a
problem, without anyone even demanding it.  Get rid of it now while you
still can!

> But one thing I definitely didn't want to do was to enable flow control
> by default, based on partner capabilites.  As it can do strange things,
> it should be opt-in.

It should always be safe to enable Tx flow control when your link partner
requests it.
It should always be safe to request Rx flow control from your link partner,
even if you never plan on sending a FC packet.

So we should just accept the negotiation.


Sidebar ________________
Readers should keep in mind that flow control must be done in hardware.
It cannot be effectively faked in software because of the timing and
priority.

When you receive a FC packet, you must stop transmitting at the end of the
current packet.  Right *now*.  You may not start transmitting a new frame,
unless you have already started the preamble.  The only packet type you are
allowed to transmit is your own FC frame.  And that FC frame must be able to
not only bypass all packet in the driver queue, but the packets already in
the Tx FIFO and serializer.

You can't just put your pause packet at the front of the driver transmit
queue, because it might not be sent until it is too late, and then will be
acted on when you don't want it to take effect.
________________

> > I recall reading a section that stated the flow control bit would be set
> > automatically based on the autonegotiation results.  Writing the upper byte
> > of Wn3_MAC_Ctrl would override the automatic setting.  Thus the driver only
> > writes the lower byte.  However, I can't find the note stating this.
> > Perhaps I just dreamed it.
> 
> Dreaming, I think.  I guess it's easy to get confused once you've
> written drivers for every adapter known to mankind...

Well, I can't be confusing it with the Intel chips.  They have a bug
where their automatic FC setting based on negotiation fails-on.  It sends
FC frames even on half duplex links.  The bug manifests itself by hosing
your network when a Linux machine crashes or shuts down without doing
'ifconfig eth0 down'.  "That'll teach you to never shut me down."

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Beowulf Clusters / Linux Installations
Annapolis MD 21403