Date: Mon, 31 Jul 2006 10:53:39 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: arch@freebsd.org, net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Changes in the network interface queueing handoff model Message-ID: <20060731105045.X16341@fledge.watson.org> In-Reply-To: <200607311024.50537.hselasky@c2i.net> References: <20060730141642.D16341@fledge.watson.org> <44CCFC2C.20402@errno.com> <20060730200929.J16341@fledge.watson.org> <200607311024.50537.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 31 Jul 2006, Hans Petter Selasky wrote: > On Sunday 30 July 2006 21:23, Robert Watson wrote: >> On Sun, 30 Jul 2006, Sam Leffler wrote: > > Just a comment while the iron is hot: > > Maybe you can make the network model safe against detach. Currently I see > that the processor can be stuck in routines like "if_start" after that > "if_free()" has been called. This can be critical for USB ethernet devices. This is something to fix in the short or long term, but I think we should not try to fix everything at once as there is an awful lot to fix. There are really two stages to fixing the ifnet life cycle, which Brooks has been working on for some time. The first is to make it generally make sense -- he moved ifnet out of the softc, has been working to normalize things generally, (add dead ifnets), etc. The second is to add new types of reference and tear-down magic. What Solaris does here, FYI, is basically add a lock around entering the device driver via their mac layer in order to prevent it from "disappearing" while in use via the ifnet interface. I'm not sure if we want the same solution there or not, but it's worth thinking carefully about. We had (and have) similar problems in a number of other places, where races between consumers of an API and a detach of the provider cause problems. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060731105045.X16341>