From owner-freebsd-arch Sat Jun 22 4:34: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id E2A3237B403 for ; Sat, 22 Jun 2002 04:33:58 -0700 (PDT) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.3/8.12.3) with ESMTP id g5MBXnMa045052 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 22 Jun 2002 13:33:52 +0200 (CEST) (envelope-from ticso@cicely5.cicely.de) Received: from cicely5.cicely.de (localhost [IPv6:::1]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g5MBXmFJ052583 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 22 Jun 2002 13:33:48 +0200 (CEST)?g (envelope-from ticso@cicely5.cicely.de) Received: (from ticso@localhost) by cicely5.cicely.de (8.12.1/8.12.1/Submit) id g5MBXjhx052582; Sat, 22 Jun 2002 13:33:45 +0200 (CEST)?g (envelope-from ticso) Date: Sat, 22 Jun 2002 13:33:45 +0200 From: Bernd Walter To: Jonathan Lemon Cc: Terry Lambert , Gary Thorpe , freebsd-arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts Message-ID: <20020622113344.GA52429@cicely5.cicely.de> Reply-To: ticso@cicely.de References: <3D1293AE.FDEC441D@mindspring.com> <20020620220712.E70387@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020620220712.E70387@prism.flugsvamp.com> X-Operating-System: FreeBSD cicely5.cicely.de 5.0-CURRENT i386 User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jun 20, 2002 at 10:07:12PM -0500, Jonathan Lemon wrote: > On Thu, Jun 20, 2002 at 07:47:10PM -0700, Terry Lambert wrote: > > The way I would suggest doing this is to run the protocol processing > > up to user space at interrupt time (LRP). This gets rid of NETISR. > > > > A lot of people complain that this won't allow you to receive as > > many packets in a given period of time. They are missing the fact > > that this only affect the burst rate until poll saturation occurs, > > at which point in time the number of packets that you receive is in > > fact clocked by buffer availability, and buffer availability is > > clocked by the ability of NETISR to process the packets up to the > > user space boundary, and that in turn is clocked by the ability to > > process the packets out to the user space programs on the other end > > of the sockets. > > > > What this all boils down to is that you should only permit receive > > data interrupts to occur at the rate that you can move the data from > > the wire, all the way through the system, to completion. > > > > The feedback process in the absence of available mbufs is to take > > the interrupt, and then replace the contents of the mubuf receive > > buffer ring with the new contents. The mbuf's only ever get pushed > > up the stack if there is a replacement mbuf allocable from the > > system in order to put on the ring in place of the received mbuf. > > Effectively, we are talking about receive ring overflow here. > > > > If you trace the dependency graph on mbuf availability all the > > way to user space, you will see that if you are receiving packets > > faster than you can process them, then you end up spending all > > your time servicing interrupts, and that takes away from your > > time to actually push data through. > > > > Jeff Mogul of DEC Western Research Laboratories described this as > > "receiver livelock" back early in the last decade. > > Yes, I believe anyone who has done work in this area is familiar > with that technical report. That still may be an interesting point. I was able to deadlock an 486 running 5.0-DP1. The machine has 100MBit interfaces. If I ping -i 0 -s 4000 the box it fills up all it's mbuf resources and is completely unuseable as long as I ping. Once all mbuf resources were used it completely locks up. My workaround was to set net.inet.ip.maxfragpackets=0. I did not recheck it with a more recent -current. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message