Received: by oss.sgi.com id ; Sun, 25 Jun 2000 09:44:48 -0700 Received: from adsl-151-196-242-4.bellatlantic.net ([151.196.242.4]:35054 "EHLO vaio.greennet") by oss.sgi.com with ESMTP id ; Sun, 25 Jun 2000 09:44:19 -0700 Received: from localhost (becker@localhost) by vaio.greennet (8.9.3/8.8.7) with ESMTP id MAA18809; Sun, 25 Jun 2000 12:45:50 -0400 Date: Sun, 25 Jun 2000 12:45:50 -0400 (EDT) From: Donald Becker X-Sender: becker@vaio.greennet To: Alan Cox cc: Andrew Morton , "netdev@oss.sgi.com" Subject: Re: [patch] 3c59x.c for 2.2.17 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Sun, 25 Jun 2000, Alan Cox wrote: > > - The driver would crash the machine if all dev_alloc_skb()'s failed > > during open(). So I simply fail the open() if we can't preallocate all > > the skb's. > > Ok The previous code would allow operation even if not all buffers could be allocated. This is a good thing. I suppose the correct operation is to refuse to start if no buffers at all can be allocated. > > - The problem reported by Mark Hemment where the rx path would die if 32 > > successive dev_alloc_skb()'s failed has been semi-kludgily fixed by > > detecting this situation in the tx interrupt and deliberately calling > > the rx ISR. This means that in cruel OOM situations we're relying on Tx > > interrupts to initiate polling for available memory. This can take some > > time if TCP has backed off a long way, but it recovers eventually. > > This is a mess in a lot of Don Becker skeleton base drivers. Its much cleaner > if the last ring buffer slot is about to be used and the new alloc fails to > simply recycle the buffer and throw the received packet away. > > Several drivers simply require the ring remains full and they are a lot cleaner > for it. All drivers used to be this way. I had to change the structure on many drivers when there were several kernel versions where the kernel would fail skbuff allocation even when there was plenty of free memory. IIRC, there were other kernel versions where using swap space didn't occur quickly enough, and there would be temporary shortages of memory that would last for several tens of milliseconds. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Annapolis MD 21403