Re: Today Linus redesigns the networking driver interface (was Re: tulip driver in ...)

Donald Becker (becker@cesdis1.gsfc.nasa.gov)
Sun, 20 Sep 1998 11:18:48 -0400 (EDT)

On Sun, 20 Sep 1998, Gerard Roudier wrote:
> On Sun, 20 Sep 1998, Donald Becker wrote:
> > On Sat, 19 Sep 1998, Theodore Y. Ts'o wrote:
> > > SPL's are just completely braindamaged. Linux does the only sane thing,
> > > Note that all of the post-BSD 4.4 implementations have abandoned SPL's
> > I've written a few BSD drivers, and I agree. The spl() approach is
> > awkward to implement and has serious performance implications for modern
> > machines. It's clear that BSD was designed for machines of a different era.
> On architectures where consistency is maintained between Hardware
> Interrupt Levels and CPU Execution Levels with regards to interruptible
> code, you can design kernel data structures so that the actual execution
> Level ensures integrity without additionnal synchronisation. When the

Yes. When a single vendor designs all of the hardware and the OS, the OS
can take advantage of the hardware structure to minimize synchronization.
I'm not saying that BSD design wasn't a good choice for the time it was
designed. But the world isn't like that anymore.

> > We have busses with shared interrupt lines and multifuction boards.
> > Masking and priority are no longer viable design assumptions.
>
> The spl mechanism encourages to access data structures, assumed to belong
> to a given level (or subsystem), directly across layers, without using
> opaque interfaces. It also encourages to do more work than needed under
> interrupt since not all interrupts are masked. I want to write that it

Yes, the BSD structure encourages doing at lot of interrupt time.
Example: the BSD networking stack is great for ping and ARP latency when you
have a single network interface. It can do everything, including
sending the response packet(!), during the receive interrupt. As someone
concerned about network performance that sounds really great to me! Until
some other subsystem thinks it can have the same luxury ;->. Or when a few
1500 byte ping packets on an ISA NE2000 blocks my 100mbps card's receive
interrupts until the end of time.

> > This leads to a great example of my previous point. AMD and Symbios have
> > multifunction SCSI+Ethernet PCI chips. 3Com has Ethernet+Modem cards.
> > Both functions share a single interrupt pin. It's no longer possible to
>
> It you are right here, these dual function boards are _not_ PCI compliant.
> Function 1 shall use INTA line and function 2 shall use INTB line.
> You may configure IRQ routing to share a single IRQ for the 2 functions of
> a dual-function PCI device, but this is not required.

A few reasons why that's not a usable design assumption for a portable OS:
BIOS assignment of INT->IRQ mapping.
PCI bus bridges.
CardBus devices.

Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/