Date: Mon, 29 Jul 2002 17:03:45 -0700 From: Peter Wemm <peter@wemm.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, freebsd-smp@freebsd.org Subject: Re: INTR_MPSAFE network drivers Message-ID: <20020730000345.E0D9F2A7D6@canning.wemm.org> In-Reply-To: <XFMail.20020729175342.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > > On 29-Jul-2002 Andrew Gallatin wrote: > > > > > > What does a network driver need to do to mark itself INTR_MPSAFE? > > Eg, do I need to get Giant before callng ether_input()? > > > > Why are no network drivers marked INTR_MPSAFE currently? > > Is the kernel not ready for mp safe network drivers? > > Probably not. Also, I think most of the current driver locks in > the network drivers probably aren't right. They really should be > replaced with the locks on the ifnet structures associated with > each instance when ifnet structure locks are added. The single beneficial thing we can do that is also really low hanging fruit is to make as many drivers as we can INTR_MPSAFE and move the checking of the hardware interrupt status register outside of giant. This allows us to more efficiently share interrupt between mpsafe and non-mpsafe drivers. The problem is that when an interrupt happens for something that is shared between mpsafe and non-mpsafe drivers, the interrupt is not reenabled again until *all* of the drivers have polled their hardware. And if your mpsafe driver shares with a non-mpsafe driver, then your processing will be held up in a lockstep while the *other* driver blocks on Giant, even if it was *your* interrupt to start with. ie: the other driver will block on giant, check the service routine and most likely then see that nothing is pending and then release giant. This murders your interrupt latency. If every driver checks its status outside of Giant, then this would not be a problem. The catch is that pci_read_config() etc is not mpsafe yet since it uses the shared pci configuration space window with no locking at all... :-] (This should be simple to fix as well, except acpi is involved too now). Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020730000345.E0D9F2A7D6>