Date: Mon, 18 Nov 2002 17:31:55 -0800 From: Luigi Rizzo <rizzo@icir.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: David Gilbert <dgilbert@velocet.ca>, dolemite@wuli.nu, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Small initial LRP processing patch vs. -current Message-ID: <20021118173155.C29018@xorpc.icir.org> In-Reply-To: <3DD99018.73B703A@mindspring.com>; from tlambert2@mindspring.com on Mon, Nov 18, 2002 at 05:12:56PM -0800 References: <20021109180321.GA559@unknown.nycap.rr.com> <3DCD8761.5763AAB2@mindspring.com> <15823.51640.68022.555852@canoe.velocet.net> <3DD1865E.B9C72DF5@mindspring.com> <15826.24074.605709.966155@canoe.velocet.net> <3DD2F33E.BE136568@mindspring.com> <3DD96FC0.B77331A1@mindspring.com> <20021118151109.B19767@xorpc.icir.org> <3DD99018.73B703A@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 18, 2002 at 05:12:56PM -0800, Terry Lambert wrote: > Luigi Rizzo wrote: ... > > This patch will not make any difference if you have device_polling > > enabled, because polling already does this -- queues a small number > > of packets (default is max 5 per card) and calls ip_input on them > > right away. > > The problem with this is that it introduces a livelock point at no it doesn't because new packets are not grabbed off the card until the queue is empty. > > I do not understand this claim: > > > > > The basic theory here is that ipintr processing can be delayed > > > indefinitely, if interrupt load is high enough, and there will > > > be a maximum latency of 10ms for IP processing after ether_input(), > > > in the normal stack case, without the patches. > > > > because netisr are not timer driven to the best of my knowledge -- > > they just fire right after the cards' interrupts are complete. > > That's almost right. The soft interrupt handlers run when you > splx() out of a raised priority level. In fact, this happens at > the end of clockintr, so NETISR *is* timer driven, until you hit i think it happens at the end of the device interrupt! > .... > Polling changes this somewhat. The top end is reduced, in exchange > for not dropping off as badly actually, this is not true in general, and not in the case of FreeBSD's DEVICE_POLLING. Polling-enabled drivers fetch the cards' state from in-memory descriptors, not from the interrupt status register across the PCI bus. Also, they to look for exceptions (which require going through the PCI bus) only every so often. So the claim that the top end is reduced is not true in general -- it depends on how the interrupt vs. polling code are written and optimised. > | > | ... <- Receiver livelock point > | * +++* > | * .++ ++++ ++++ ++++ ++++ +++ > | * . + + + + + > | * . > | * . > |* . > |* . > |* ......................... > +-------------------------------------------- > > The reason the top end is depressed is that the polling is not load > adaptive. Instead, it is fixed overhead relative (e.g. the use of > the hardclock to effect calls to ether_poll(), which then calls into > all drivers, whether they have data available or not, to fetch state > across the PCI bus to ask the cards if there is data available. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021118173155.C29018>