netdev
[Top] [All Lists]

Re: 802.3x flow control

To: Donald Becker <becker@xxxxxxxxx>, Andrew Morton <andrewm@xxxxxxxxxx>
Subject: Re: 802.3x flow control
From: Andrey Savochkin <saw@xxxxxxxxxxxxx>
Date: Tue, 4 Jul 2000 14:36:05 +0800
Cc: "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>
In-reply-to: <Pine.LNX.4.10.10007011133120.6225-100000@vaio.greennet>; from "Donald Becker" on Sat, Jul 01, 2000 at 12:37:30PM
References: <395E0686.BC319D33@uow.edu.au> <Pine.LNX.4.10.10007011133120.6225-100000@vaio.greennet>
Sender: owner-netdev@xxxxxxxxxxx
Hello,

On Sat, Jul 01, 2000 at 12:37:30PM -0400, Donald Becker wrote:
> 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

Thanks for the comments.
However, I need to mention that you handle the out-of-buffers condition not
very well, at least in eepro100.
The first obvious point is that you shouldn't restart RU under such
conditions in receiver-not-ready path of speedo_interrupt().  Otherwise the
card immediately and completely hangs.

As an additional note to the recent netdev discussion, I should admit that I
was too quick with my comments.
The current eepro100 drivers in 2.2.16 and 2.4.0 do allow the card to reach
to end of RX buffer ring and stop operations.  However, they delay and do
not pass to the upper layers the last buffer from the ring, for a completely
different reason.  Certainly, as Andrew's mentioned, this part of code is a
bit messy, and I hope to clean it up later.

> have, and it was explicitly changed for this reason.  You have to understand
> the Big Picture.

I wish we heard about code author's intentions more frequently...

Best regards
                Andrey

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