> This is one of my complaints. The BSD stack has a defined set of "objects"
> for dealing with networking; an incomplete list:
> protocol structure for different address families
We have these.
> interface structure for different media types
We have these
> socket structure that cleanly handles different protocols
We have most of this.
> Another big plus of the BSD stack is tcp_input.c and tcp_output.c. These
> are what most people mean when they say "BSD networking".
Yep. For 2.0 we have all the core stuff. For pre 2.1 we have stuff going beyond
what BSD is doing - Vegas flow control. If you want to work on stealing and
stuff in talk with Pedro Roque, get pre 2.1 and take a good look.
> . There are layering "invariants" that affect performance: you really
> should allocate your send buffers from the interface driver, because
> it could do some interesting things that would minimize cache flushing.
> I think Van's prototype did this for witless cards.
We could certainly add the allocate via device at very little cost. We just
using dev->kmalloc(). Note that you can't always win on this a packet may change
> . Single processor design. This is the biggest drawback, IMO.
The Linux one is semi designed for MP work. A given socket can do its own
and there are only a small number of areas of overlap at the moment. Notably
Demultiplex table needs locks
Multiple processor writes in parallel/reads in parallel on datagram requires
10 lines of lock code.
We dont run the net_bh() in parallel although most of it we can do very easily.
> . Come up with a strawman proposal for the set of "objects" we think
> we need in Linux. Do this as part of the work Linus suggested to
> merge the socket ops with the vfs ops.
That certainly cant be counter-productive.
> . Steal the TCP code outright. Nuke the mbuf stuff, use the skbufs
> or a slightly modified version thereof.
We can't steal it outright. 4.4BSD has abominable problems as is. The FreeBSD
have the worst of them fixed but don't have stuff like Vegas and have all the
horrible spoofing problems caused by bad timers.
> . Design in SMP support from the start. This means thinking about
> thousands of connections running in parallel.
So long as it still runs very fast for the 99.99% of people with a single CPU
Thats the primary target by market volume.
> : 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.
> Yeah, but a very reasonable point is "we don't have that". BSD does.
> This is a big deal. Documentation is useful.
Its coming. In fact AW should now have released an English language version of
1.2 kernel programming book.