Date: Sat, 22 Jun 2002 13:33:45 +0200 From: Bernd Walter <ticso@cicely5.cicely.de> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: Terry Lambert <tlambert2@mindspring.com>, Gary Thorpe <gat7634@hotmail.com>, freebsd-arch@FreeBSD.ORG Subject: Re: multiple threads for interrupts Message-ID: <20020622113344.GA52429@cicely5.cicely.de> In-Reply-To: <20020620220712.E70387@prism.flugsvamp.com> References: <F112l4rhYQYx3G5aYY6000252ae@hotmail.com> <3D1293AE.FDEC441D@mindspring.com> <20020620220712.E70387@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020622113344.GA52429>