Date: Sat, 20 Jan 1996 14:09:03 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: chuckr@glue.umd.edu (Chuck Robey) Cc: wollman@lcs.mit.edu, leisner@sdsp.mc.xerox.com, freebsd-questions@FreeBSD.org Subject: Re: streams Message-ID: <199601202109.OAA12171@phaeton.artisoft.com> In-Reply-To: <Pine.SUN.3.91.960119204530.9487C-100000@espresso.eng.umd.edu> from "Chuck Robey" at Jan 19, 96 08:47:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > It is well-known to be disadvantageous to actually /use/ streams. > > Garrett, I originated this stream, asking Mike Smith if he knew of any > streams-negativisms. Sounds like you do, would you care to amplify? I'm > really curious, because they seem like (to me) an analog to stackable > filesystems, for character io. Why not? Garrett will probably answer too, but your analogy fails. The file system stacking works by using a call vector table for the top end of the FS, and percolating call vectors up from the lower layers for null layers in the current layer. Which is to say, it has minimal overhead. In Streams, the upcall/downcall mechanism can't easily "collapse" empty layers to get similar efficiency. This leads to large latencies in Streams, while the stacking vnode interface only adds overhead for interfaces that actually do something, not just pass the call on. Streams is typically scheduled to run just before a process exits the system call trap code back to user space after a system call, with several additional preemption points where streams will preferrably run. But each layer traversal requires Streams to be scheduled to run, so a traversal of a full TCP/IP stack with an underlying DDI/DKI driver at the stream tail can take upwards of 6 or 7 preemption points to actually run. There has been some work on "monoblock" protocol implementations, where you have a single module with promiscuous knowledge of interfaces internally that exports multiple stack interfaces. For instance, I could have a single module that exported TCP, UDP, IP, ICMP, and RIP interfaces, but internally used non-Streams techniques to communicate between layers. This work is not very practical for more than a couple of high performance Streams heads, with everything built on top of them (the code reuse argument that semi-justifies streams in the first place) suffering the same penalties as usual because of the use of ordinary streams interfaces. The closest work to a stackable vnode architecture has been X-Kernel, though it has its own problems of stack implementation availability... it works, but there's very little to run. Probably, it would take kernel threading and pseudo-RT scheduling class support to make much of the latency go away. Then, on top of that, you would probably want to pass around data pointers rather than copying data into an mbuf when crossing the user/kernel boundry. This adds the mapping complication of not having the caller process context at the time Streams is actually run, so you would have to establish fixed kernel mappings for pages, and the user/kernel boundry crossing would seek to establish a translation for the fixed mapping address. So the primary utility for streams is for use of stack drivers from commercial sources and for the simplified developement environment (justified if you consider Streams stacks to be prototypes rather than production code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601202109.OAA12171>