Path: utzoo!mnetor!uunet!husc6!think!ames!hc!lll-winken!lll-lcc!pyramid!ctnews!mitisft!jimb
From: jimb@mitisft.Convergent.COM (Jim Bennett)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <330@mitisft.Convergent.COM>
Date: 23 Mar 88 22:00:44 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA> <4441@megaron.arizona.edu>
Organization: Convergent Technologies, San Jose, CA
Lines: 24
Summary: STREAMS performance is fine, if drivers correctly written

In article <4441@megaron.arizona.edu>, lm@arizona.edu (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 copying dominates
> the time spent in the streams drivers.  If streams can handle imbedded 
> pointers in their data then my comments are meaningless.)

In general, it is not necessary to copy data in order to pass it
downstream (or upstream).  STREAMS comes with a set of procedures
for pulling message blocks from queues, adding them to queues,
linking messages together, etc.

The only reasons I can think of why data might need to be physically
copied:  If message boundaries need to be changed, or if the data
needs to be processed in a way that causes data expansion and the
current streams buffer overflows.

More to the point:  At Convergent we have converted the 4.3 BSD
TCP/IP from a sockets interface to a STREAMS interface and measured
no loss in performance.

Jim Bennett
Convergent Technologies
...!uunet!pyramid!ctnews!mitisft!jimb