Date: Mon, 1 Jun 2009 19:41:46 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: New NETISR implementation, but same defaults Message-ID: <alpine.BSF.2.00.0906011939510.52806@fledge.watson.org> In-Reply-To: <200906011757.31908.hselasky@c2i.net> References: <alpine.BSF.2.00.0906011141530.27214@fledge.watson.org> <200906011757.31908.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 1 Jun 2009, Hans Petter Selasky wrote: > On Monday 01 June 2009, Robert Watson wrote: >> As a HEADS up to 8-CURRENT followers: I've replaced the NETISR >> implementation there as part of on-going work to improve network stack >> parallelism, details below. In practice, most behavior remains identical >> in the default configuration (direct dispatch, single netisr thread that's >> not bound to a CPU, etc), but people will want to watch out for problems. >> Some default queue limits have been raised. >> >> More functional changes to take advantage of these features, such as >> deferred ethernet dispatch and software flow ID generation, will follow as >> patches, but probably not ship in 8.0 out of the box. > > Having WITNESS and INVARIANTS in the kernel config I get a panic about a > NULL mutex when running "dhclient wlan0". Prior to running dhclient wlan0 > has been properly setup. CPU: 2-HTT This should be fixed in r193243. I made a change shortly before merging that locks the current CPU's workstream before billing packets to it when direct dispatching, and this turns out to be incorrect, as on systems with fewer workers than CPUs, then we lock an uninitialized mutex. Let me know if the above change doesn't fix it. Robert N M Watson Computer Laboratory University of Cambridge > > Workaround: > > net.isr.direct=0 > net.isr.direct_force=0 > > --HPS >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0906011939510.52806>