From: David Gwynne l...@animata.net
Date: Wed, 23 Mar 2011 14:21:19 +1000
makes sense to me.
While it is a potential solution for the problem at hand (and one I
didn't consider yet) can we step back and think whether this is a
solution that will work for *all* our ethernet drivers?
On
On Wed, Mar 23, 2011 at 08:17:11AM +0100, Mark Kettenis wrote:
From: David Gwynne l...@animata.net
Date: Wed, 23 Mar 2011 14:21:19 +1000
makes sense to me.
While it is a potential solution for the problem at hand (and one I
didn't consider yet) can we step back and think whether this
The timeout seems like a very large amount of time.
All the drivers used to contain reuse-the-last-mbuf tricks. With
MCLGETI, this hack is removed because MCLGETI should provide at least
1 mbuf. But... what if the actual total mbuf pressure is so high that
MCLGETI can't get it. Then a driver
armani also pointed out the same issue with
my MCLGETI diff for xl(4).
I've adapted bluhm's patch and it works fine
here.
Any feedback ?
Index: src/sys/dev/ic/xl.c
===
RCS file: /cvs/src/sys/dev/ic/xl.c,v
retrieving revision 1.99
Hi,
When the kernel runs out of mbuf clusters, the hme receive ring may
become empty. In that case, the hme driver cannot recover as the
ring is only filled after receiving data. My fix is to fill an
empty receive ring every second.
ok?
bluhm
Index: dev/ic/hme.c
makes sense to me.
On 23/03/2011, at 10:28 AM, Alexander Bluhm wrote:
Hi,
When the kernel runs out of mbuf clusters, the hme receive ring may
become empty. In that case, the hme driver cannot recover as the
ring is only filled after receiving data. My fix is to fill an
empty receive
