gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/23/88)
In article <4441@megaron.arizona.edu> lm@megaron.arizona.edu.UUCP (Larry McVoy) writes: >(It should be obvious but I'll drive it home: the streams code that I've >seen copies the data out of the upper level buffer and then into the >lower level buffer [assuming "downward" movement]. The only data copy that should normally take place is between user-mode data space and the nearest streams buffer, also between the farther streams buffer and the net device. Streams module-to-module data transfer should occur by transferring packet pointers whenever possible. (I haven't examined SVR3 code to see if this is how it typically does things.)
dougm@ico.ISC.COM (Doug McCallum) (03/24/88)
In article <7526@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >The only data copy that should normally take place is between user-mode >data space and the nearest streams buffer, also between the farther >streams buffer and the net device. Streams module-to-module data >transfer should occur by transferring packet pointers whenever possible. >(I haven't examined SVR3 code to see if this is how it typically does >things.) This is exactly how most of the Streams modules I've seen (and all that I've written) work. Even splitting a buffer in two usually only requires duplicating the message block and adjusting pointers if the data isn't being modified. This is similar in concept to the mbuf code in BSD networking but with more buffer sizes. One possible enhancement that would eliminate some of the copying at the Stream head would be to detect when user level data falls within a page and map that page in a copy-on-write manner into the Streams buffer space. If the data wasn't modified before it reached the device, the initial copy would be eliminated. I haven't thought through the details and just mention it as a way a specific implementation can work around the data copy problem in some cases. In general, the Streams mechanism is no worse than other "buffered" I/O mechanisms with respect to performance and in many ways is better (such as the formalized message passing mechanism and variable buffer sizes). Probably the biggest problem with Streams in the current implementations I've seen is the static buffer pool. That is a specific implementation issue and not a problem with Streams itself.