8.0 network stack MPsafety goals
Robert Watson
rwatson at FreeBSD.org
Mon Dec 24 02:43:29 PST 2007
Dear all:
With the 7.0 release around the corner, many developers are starting to think
about (and in quite a few cases, work on) their goals for 8.0. One of our
on-going kernel projects has been the elimination of the Giant lock, and that
project has transformed into one of optimizating behavior on increasing
numbers of processors.
In 7.0, despite the noteworth accomplishment of eliminating debug.mpsasfenet
and conditional network stack Gian acquisition, we were unable to fully
eliminate the IFF_NEEDSGIANT flag, which controls the conditional acquisition
of the Giant lock around non-MPSAFE network device drivers. Primarily these
drivers are aging ISA network device drivers, although there are some
exceptions, such as the USB stack.
This e-mail proposes the elimination of the IFF_NEEDSGIANT flag and associated
infrastructure in FreeBSD 8.0, meaning that all network device drivers must be
able to operate without the Giant lock (largely the case already). Remaining
drivers using the IFF_NEEDSGIANT flag must either be updated, or less ideally,
removed. I propose the following schedule:
Date Goals
---- -----
26 Dec 2007 Post proposed schedule for flag and infrastructure removal
Post affected driver list
26 Jan 2008 Repost proposed schedule for flag and infrastructure removal
Post updated affected driver list
26 Feb 2008 Adjust boot-time printf for affect drivers to generate a loud
warning.
Post updated affected driver list
26 May 2008 Post HEADS UP of impending driver disabling
Post updated affected driver list
26 Jun 2008 Disable build of all drivers requiring IFF_NEEDSGIANT
Post updated affected driver list
26 Sep 2008 Post HEADS up of impending driver removal
Post updated affected driver list
26 Oct 2008 Delete source of all drivers requiring IFF_NEEDSGIANT
Remove flag and infrastructure
Here is a list of potentially affected drivers:
Name Bus Man page description
--- --- --------------------
ar ISA/PCI synchronous Digi/Arnet device driver
arl ISA Aironet Arlan 655 wireless network adapter driver
awi PCCARD AMD PCnetMobile IEEE 802.11 PCMCIA wireless network
driver
axe USB ASIX Electronics AX88172 USB Ethernet driver
cdce USB USB Communication Device Class Ethernet driver
cnw PCCARD Netwave AirSurfer wireless network driver
cs ISA/PCCARD Ethernet device driver
cue USB CATC USB-EL1210A USB Ethernet driver
ex ISA/PCCARD Ethernet device driver for the Intel EtherExpress
Pro/10 and Pro/10+
fe CBUS/ISA/PCCARD Fujitsu MB86960A/MB86965A based Ethernet adapters
ic I2C I2C bus system
ie ISA Ethernet device driver
kue USB Kawasaki LSI KL5KUSB101B USB Ethernet driver
oltr ISA/PCI Olicom Token Ring device driver
plip PPBUS printer port Internet Protocol driver
ppp TTY point to point protocol network interface
ray PCCARD Raytheon Raylink/Webgear Aviator PCCard driver
rue USB RealTek RTL8150 USB to Fast Ethernet controller driver
rum USB Ralink Technology USB IEEE 802.11a/b/g wireless
network device
sbni ISA/PCI Granch SBNI12 leased line modem driver
sbsh PCI Granch SBNI16 SHDSL modem device driver
sl TTY slip network interface
snc ISA/PCCARD National Semiconductor DP8393X SONIC Ethernet adapter
driver
sr ISA/PCI synchronous RISCom/N2 / WANic 400/405 device driver
udav USB Davicom DM9601 USB Ethernet driver
ural USB Ralink Technology RT2500USB IEEE 802.11 driver
xe PCCARD Xircom PCMCIA Ethernet device driver
zyd USB ZyDAS ZD1211/ZD1211B USB IEEE 802.11b/g wireless
network device
In some cases, the requirement for Giant is a property of a subsystem the
driver depends on as the driver itself; for example, the tty subsystem for
SLIP and PPP, and the USB subsystem for a number of USB ethernet and wireless
drivers. With most of a year before to go on the proposed schedule, my hope
is that we will have lots of time to address these issues, but wanted to get a
roadmap out from a network protocol stack architecture perspective so that
device driver and subsystem authors could have a schedule in mind.
FYI, the following drivers also reference IFF_NEEDSGIANT, but only in order to
provide their own conditional MPSAFEty, which can be removed without affecting
device driver functionality (I believe):
Name Bus Man page description
--- --- --------------------
ce PCI driver for synchronous Cronyx Tau-PCI/32 WAN adapters
cp PCI driver for synchronous Cronyx Tau-PCI WAN adapters
ctau ISA driver for synchronous Cronyx Tau WAN adapters
cx ISA driver for synchronous/asynchronous Cronyx Sigma WAN
adapters
Developers and users of the above drivers are heavily encouraged to update the
drivers to remove dependence on Giant, and/or make other contingency plans.
Robert N M Watson
Computer Laboratory
University of Cambridge
More information about the freebsd-arch
mailing list