[openbeosnetteam] Re: Net Stack

I find this to be a pretty interesting idea. Axeld and others may remember an admin team meeting, some time ago, when I proposed the idea of implementing networking is user land, using some area tricks to prevent the need for multiple copies. Axeld very patiently and wisely reminded me that task switching between the net_server, kernel (for network card interrupts) and the app would kill the performance. If I had taken the idea to the logical extension that Van here came to, I could have been on lwn! :-)

Actually, this sort of ties into the buffering question, too.

I know this is pretty much a noob question - I am not a networking guru, but I do want to learn some. :-) How much data does the networking stack add to a packet that comes in? In the one networking course that I took, the way that it was explained was that there were/are wrappers for each layer of the protocol. So there is a layer 1 (hardware) wrapper that has physical addresses, I guess, in it. Then a layer that has ethernet data in it. Then a TCP wrapper that has some data. Etc.

My question is really this - if we get a packet of N bytes, isn't the data actually delivered to the application N - W bytes, where W is the "waste" of the delivery info, etc? If that is so, don't we really know, in advance, how much to allocate? This seems overly simplistic, so I am sure that it isn't the case, and I look forward to the reason why. :-)

Likewise, in the other direction - if app X says "send data N", isn't it predictable how much buffer space you would need?

I look forward to the joint opinion on Van's article as well as my N00B questions. :-)

Tom wrote: 
Hi,

I don't even really follow the development anymore let alone develop,
but I just wanted to make sure you'd seen the recent discussion of Van
Jacobson's net channels. The talk was presented at Linux.conf.au and
covered moving the key parts of the network stack into userspace to
avoid lock contention.

This design seems like the BeOS way, it gives much higher throughput and
allows for way better scalability on N-way systems.

There is certainly merit in going with what works and hase been done
before. But it just seems like you have no legacy problems to trying
this fresh new idea. Linux can't do it since it needs to stay compatible
with netfilter/iptables/...

A good first read on the subject is here http://lwn.net/Articles/169961/

Tom Young



Other related posts: