Date: Fri, 3 Sep 2004 07:31:23 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Gordon Bergling <gbergling@0xfce3.net> Cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/sys/conf options src/sys/sys kernel.h src/sys/net netisr.c Message-ID: <Pine.NEB.3.96L.1040903072542.45860A-100000@fledge.watson.org> In-Reply-To: <20040903104015.GA1889@nemesis.md.0xfce3.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 3 Sep 2004, Gordon Bergling wrote: > > Change the default disposition of debug.mpsafenet from 0 to 1, which > > will cause the network stack to operate without the Giant lock by > > default. This change has the potential to improve performance by > > increasing parallelism and decreasing latency in network processing. > > In Consideration of some recent emails on the current mailinglist I am > not sure whether I should add NET_WITH_GIANT to my kernel config or not. > > In my LAN I take heavy usage of IPv6 and one of NICs (vr driver) is not > yet marked MP_SAFE. > > Is it safe for now to switch over to debug.mpsafenet=1 or should I wait > until the locking of IPv6 is done? > > BTW. I am very willing to help testing... ;) :-) if_vr has recently had its locking reviewed (and in many cases corrected) by Bruce Simpson, so I think it is probably reasonable to run w/o Giant even though it wasn't on my list of known good drivers. He's marked it as INTR_MPSAFE (inbound path runs w/o giant), and not marked it IFF_NEEDSGIANT (outbound path runs w/ giant). Regarding IPv6: significant parts of IPv6 are safe in an MPSAFE environment, but not very well tested -- I've had about three or four minor but significant (fail stop) bugs to correct in the last two weeks. I don't doubt more are waiting. Areas that still require substantial attention in locking include the IPv6 forwarding path, ip6fw, and multicast discovery/routing. If you're using IPv6 on a local system largely for services like TCP consumption and serving, you are probably OK, but might encounter fail stop (assertion failure) scenarios that require some debugging. So far, these problems have generally been resolved within 48 hours of the problem being reported. So if you're willing to do a bit of testing, MPSAFE operation is probably ready for you, and additional IPv6 testing is something I'd like to see more of, as I don't have easy access to a rich IPv6 environment. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040903072542.45860A-100000>