Date: Tue, 30 Jul 2002 09:30:13 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Peter Wemm <peter@wemm.org> Cc: John Baldwin <jhb@FreeBSD.org>, freebsd-smp@FreeBSD.org Subject: Re: INTR_MPSAFE network drivers Message-ID: <15686.38117.385391.893080@grasshopper.cs.duke.edu> In-Reply-To: <20020730000345.E0D9F2A7D6@canning.wemm.org> References: <XFMail.20020729175342.jhb@FreeBSD.org> <20020730000345.E0D9F2A7D6@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm writes: > 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. Yes, making my driver INTR_MPSAFE gets back about half of the performance lost when moving from -stable to -current. ;-) > 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). Ugh. That sounds quite nasty. Drew 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?15686.38117.385391.893080>