From owner-freebsd-net Fri Feb 9 9:56: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 3C21837B6A4 for ; Fri, 9 Feb 2001 09:55:32 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14RHug-0000JW-00; Fri, 09 Feb 2001 11:04:54 -0700 Message-ID: <3A843146.BFC863B9@softweyr.com> Date: Fri, 09 Feb 2001 11:04:54 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman Cc: Luigi Rizzo , net@FreeBSD.ORG Subject: Re: potential infinite loop in network device drivers References: <200102090102.f19125x06386@iguana.aciri.org> <200102090209.VAA60712@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman wrote: > > < said: > > > it occurs to me that there is a potential infinite loop in > > most if not all ethernet drivers. Basically, on a > > receive interrupt, such drivers loop around the status word > > until the receive queue is drained. > > One possible right way to deal with this is to get rid of the > two-level interrupt scheme (for fast interfaces at least) and push the > packets all the way through the network stack. This will ensure that > if packets are arriving faster than we can handle them, they will be > dropped by the network interface with an ``insufficient resources'' > error. > > Another possible right way to deal with this is to move all network > processing into the lower level, and poll round-robin for packets > (with network interrupts disabled) until all network interfaces are > finished (or we need to give the user a time slice). This is similar to the way most VxWorks network drivers operate: the "packet available" interrupt handler simply schedules tNetTask to retrieve the packet using a driver-specific callback function. If the buffer on the network card gets filled up before tNetTask can get around to it, packets are dropped until the system becomes less busy. The programmer can tune the behavior by juggling the priorities of tNetTask and other busy parts of the system. This helps to avoid the problems of too many receive interrupts driving the system into interrupt livelock, as long as the card is smart enough to discard packets without interrupting when its own buffers are full. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message