Messages in this thread |  | | Date | Tue, 05 Nov 1996 12:16:30 -0500 (EST) | From | "Mark H. Wood" <> | Subject | Re: User-space Networking (Was; unusual startup messages) |
| |
On Fri, 1 Nov 1996, Craig Milo Rogers wrote:
> >> >Yes, you can do it in user space, but your performance will suck unless you > ... > >> Actually, the hardware needn't be that special. It mainly > >> needs to identify "normal" incoming TCP and UDP packets, and store > ... > >Yes, you can get _some_ networking going that way, but you sure as hell > >aren't going to get UNIX semantics. Another favourite pastime of > ... > > You have raised some very cogent points. To save space, I > have not quoted your message in detail. Instead, I'll focus on some > overall application and OS design issues involved (and that way I'll > also feel a little better about using bandwidth on linux-kernel). > > Another approach is to implement user-level TCP/IP in the > dedicated server processes, and have a user-level TCP/IP process act > as a daemon (ala kerneld) for all other network-using processes. It > is fairly easy to imagine how to implement this and preserve full Unix > semantics for the processes that require them. The cost is fairly > high, of course, due to the multiple user/kernel/user context switches > required to pass data and control between processes. However, *if* > the bulk of system processing is in the dedicated server processes, > which are not subject to these context switches, then the increased > overhead in the other processes may be negligible to the system as a > whole.
As a point of reference, this is approximately the way network stacks are implemented on VMS. The kernel just handles the physical devices. Daemons responsible for the various stacks register their interest in certain packet types and provide buffer chains which the drivers use for packet exchange. A program's connection(s) to the stack(s) it uses will be through a mailbox device (very like a pipe). With careful design, much of the data "transfer" can be accomplished by fiddling with various processes' page maps instead of bulk copying.
There's a close relationship between the kernel and DECnet, but UCX and Pathworks seem to give acceptable performance without it. (At any rate, most of the complaints about UCX haven't been over performance. :-/ )
FWIW.
Mark H. Wood, Lead System Programmer MWOOD@INDYVAX.IUPUI.EDU Those who will not learn from history are doomed to reimplement it.
|  |