Date: Tue, 18 Dec 2001 10:47:50 -0600 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Bruce Evans <bde@zeta.org.au> Cc: Luigi Rizzo <rizzo@aciri.org>, arch@FreeBSD.ORG Subject: Re: swi_net Message-ID: <20011218104750.M377@prism.flugsvamp.com> In-Reply-To: <20011219010205.P4481-100000@gamplex.bde.org> References: <20011213091957.B39991@iguana.aciri.org> <20011219010205.P4481-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 19, 2001 at 01:25:58AM +1100, Bruce Evans wrote: > On Thu, 13 Dec 2001, Luigi Rizzo wrote: > > > we have 2 slightly different versions of swi_net in -current and > > -stable, listed below (STABLE/Alpha is approximately the same as > > CURRENT). > > > > I like a lot the semantics of the version in -stable, because it > > enforces a strict priority in the execution of soft handlers > > (remember they are not preemptable), even when schednetisr(FOO) is > > called within one of the handlers. > > I prefer the -stable version too, but I think the strict priority > doesn't make much difference. Anyway, it's not completely strict, > because lower priority handlers are not preemptable. I'm planning on revising swi_net so that it is possible to run all network processing under the device interrupt instead of deferring things to a netisr(). This also has the advantage of eliminating all ipintr() style loops, as packet dequeueing is done in a centralized place, and makes it easier to bound the amount of work which is done. (Actually, the interface queues and netisrs are not completely gone; it is possible to switch back and forth dynamically) I have this working on -stable (the more difficult of the two, IMO) and it should be easy to extend this to -current. This will permit removal of Luigi's ether_pollmore() and associated cruft, since all packet handling relating to polling would be run in a single netisr 'thread'. -- Jonathan PS: > -current is also missing the optimization of initializing the table with > dummies so that it doesn't need to check the pointer. Unexpected netisrs > could be handled even better by panicing for them. Yeah, I saw that. However, panic'ing in a netisr (which I did several times over the weekend) appears to produce a stream of faults, eventually wedging the box so that it needs a powercycle. 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?20011218104750.M377>