Subject: linux needs bsd networking stack

From: [email-masked] (Neal Nuckolls)
Date: Wed, 29 May 1996 14:59:58 -0700

Silicon Valley is bubbling with networking startups.
Many of these new small companies are designing products
based on PC motherboards and doing some sw and/or hw
customization to turn them into networking switches,
routers, firewalls, etc.  Rather than embedding a RTOS,
they are choosing a free unix and usually this is FreeBSD
since Linux networking is not the de facto BSD stack.
The "unique" tcp/ip implementation is a liability to linux.
Is anyone working to replace the standard linux stack
with port derived from the 4.4BSD code?

thanks.

neal nuckolls
[email-masked]

---

From: "David S. Miller" <[email-masked]>
Date: Wed, 29 May 1996 15:50:23 -0700

Date: Wed, 29 May 1996 14:59:58 -0700
   From: nn@lanta (Neal Nuckolls)

It could also be one of it's greatest assets, and I think this will
turn out to be the case.

I will for now only briefly mention why I think this is not very
desirable.

A couple of weeks ago, Larry was babbling to me "oh the stack is
sloowww, I can't push nearly as much over 100mb/s ether as freebsd
can, etc."  I said, "thats peculiar" so I did some investigation and
told Linus about it.  Turned out to be a driver bug and after that was
fixed the over the wire numbers are unparalleled.

The Berkeley stack is dead, but it has one redeeming quality which
Linux's stack does desperately need.

It has a well defined architecture, I will agree with lm when he
mentions that it is a jungle of code to sift through in certain
respects.  It need a mallet to smooth certain aspects and interfaces
out.

In the end I think it is best to work on hacking the existing (and
upcoming) Linux networking code to have these qualities instead of
stuffing the bsd stack into linux (this has been done before a long
long time ago btw, before linux had any networking, a man by the name
of Charles Hedrick back at Rutgers did it in a few nights).

I think the feeling that the linux stack is "hard to follow" or "has
very little architecture" has a lot to do with the fact that we don't
have 20 books analyzing the code c-statement by c-statement like the
bsd stuff does.  If we had that, I think this desire to use the
berkeley stack would not be as strong.

I dislike the berkeley stack, but I am biased in my opinion.  I am
biased because of the attitude expressed by the people actively
working on that code set in the free software world these days, I am
also biased because I tend to hack Linux almost exlusively.  But, even
barring that I believe that some of the elements of the bsd stack will
end up being completely flawed when plugged into linux, obvious things
like mbufs and other things come to mind right now.  It would require
a bit of engineering and greatly upset a large community who has put
their entire heart and soul into the Linux networking code.  I believe
at the very least that the Linux networking stack is superior
performance wise without any question, and as everyone knows I have
numbers to prove it ;-)

Later,
David S. Miller
[email-masked]

---

From: Linus Torvalds <[email-masked]>
Date: Thu, 30 May 1996 08:21:42 +0300 (EET DST)

> with port derived from the 4.4BSD code?

Simple answer: it won't happen.

The _only_ advantage of the BSD stack is the de-facto standard thing, and 
quite frankly that one doesn't make much of a difference - Linux _will_ 
be the facto standard in one or two more years if everything goes right. 
Trying to port the BSD stack would be a major mistake, imho.

I used to think the BSD stack was an option that we might want to take some
day, but I don't think so any more. My main concerns were performance and
compatibility, and we've got them both. The problems we still have in
networking are not worth worrying about in this context - we'd have a lot
more problems if we tried to switch and they wouldn't be any easier to solve. 

Note that this doesn't mean we shouldn't look at parts of the BSD stack 
for interesting things (and the BSD stack has obviously been there as a 
reference). But a whole-sale BSD stack port is not going to happen.

		Linus

---

From: Alan Cox <[email-masked]>
Date: Thu, 30 May 1996 10:43:42 +0100 (BST)

> since Linux networking is not the de facto BSD stack.

So we should use a defacto BSD stack because its a defacto stack. Ok there is this
great OS called windows3. See you later

> The "unique" tcp/ip implementation is a liability to linux.

I'm not convinced it is. A whole load of SGI people (LM notably) seem intent on "BSD
stack, BSD stack, BSD stack". Everyone else I hear is saying "How fast can it go",
"How stable can we make it", "Will you please make sure its as solid in 2.0 as in 1.2"

> with port derived from the 4.4BSD code?

No -

o	The BSD stack doesnt do IPX, AX25, NetROM, Appletalk
o	There will be no defacto IPv6 for BSD, there are several species
o	The licensing doesnt permit the two to meet easily
o	You can't do 400Mbits/second with mbufs so you'd have to break the BSD code
	anyway

Im not convinced about the rest of the argument either. I know one big vendor using
the BSD stack for a project. I know several using Linux (Things like the firewall
from Mazama). We are seeing primary rate ISDN support for Linux starting to appear,
and already have the heavy provider end multiple serial cards.

For routers, anyone using a PC style architecture is bounding themselves to small
routers anyway. No matter how good the code is you will soon need fancy hardware to
handle BGP4, 50,000 routes and fast 100baseT speed switching. And there is no
defacto BSD IPv6

Alan

---

From: Alan Cox <[email-masked]>
Date: Thu, 30 May 1996 10:46:46 +0100 (BST)

> respects.  It need a mallet to smooth certain aspects and interfaces

I hope to be working full time on this eventually (like when people are paying me
for it). I've also started documentation at the driver and skbuff level and will
work over it bit by bit - see forthcoming Linux Journal articles then going into the
KHG.

> performance wise without any question, and as everyone knows I have

Before you admire the performance numbers get the pre2.1 code off Pedro Roque. Now he
has added really neat header prediction code it kicks pre2.0's butt even though its
doing a surplus memory alloc we need to tidy up

Alan