From owner-freebsd-smp Mon Jul 29 17: 3:56 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BE8D37B400; Mon, 29 Jul 2002 17:03:54 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03A5343E3B; Mon, 29 Jul 2002 17:03:50 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id E0D9F2A7D6; Mon, 29 Jul 2002 17:03:45 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: John Baldwin Cc: Andrew Gallatin , freebsd-smp@freebsd.org Subject: Re: INTR_MPSAFE network drivers In-Reply-To: Date: Mon, 29 Jul 2002 17:03:45 -0700 From: Peter Wemm Message-Id: <20020730000345.E0D9F2A7D6@canning.wemm.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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