Date: Tue, 18 Dec 2001 14:55:38 -0800 From: Luigi Rizzo <rizzo@aciri.org> To: Bosko Milekic <bmilekic@technokratis.com> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, Bruce Evans <bde@zeta.org.au>, arch@FreeBSD.ORG Subject: Re: swi_net Message-ID: <20011218145538.A89864@iguana.aciri.org> In-Reply-To: <20011218175421.A37567@technokratis.com> References: <20011213091957.B39991@iguana.aciri.org> <20011219010205.P4481-100000@gamplex.bde.org> <20011218104750.M377@prism.flugsvamp.com> <20011218134149.A89299@iguana.aciri.org> <20011218175421.A37567@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 18, 2001 at 05:54:21PM -0500, Bosko Milekic wrote: ... > While we're on the subject, running the stack in interrupt context > seems to be an attempt to, mainly, remedy the load problem where we have > a lot of interrupts and the soft int thread doesn't even get a chance to > run... so we have a sort of livelock situation. For the cases that you yes that was the part I was in favour with... > describe, how effective do you think it would be to do as we presently > do and just schedule the soft net thread to run, return from the > interrupt but, when under load figure out a way to bump up the priority > of the softnetisr thread enough so that it does get a chance to run? the polling code in -current tries to do exacly this, and it is reasonbly self-adjusting: it grabs a small amount of packets from the interfaces, then processes the netisr to completion, then grabs more packets, and so on. Additionally, it guarantees that user tasks have a fraction of the CPU available, so if this traffic involves userland processing at least we avoid complete livelock. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- 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?20011218145538.A89864>