> >> >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.