Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!aplcomm!uunet!lanai!ron
From: ron@Eyring.COM (Ron Holt)
Newsgroups: comp.realtime
Subject: Re: Real-time Unix read()s?
Message-ID: <1990Nov29.175926.26422@Eyring.COM>
Date: 29 Nov 90 17:59:26 GMT
References: <1990Nov19.161402.7646@Eyring.COM> <dale.659144930@convex.convex.com>
Organization: Eyring, Inc.
Lines: 42

In article <dale.659144930@convex.convex.com> dale@convex.com (Dale Lancaster) writes:

>Unless you go through a buffer cache, most device drivers I have seen
>or written for Unix uses the process' own buffer to transfer data
>directly to/from without the intermediate copying to an internal buffer.
>So providing a rread() seems redundant or unnecessary since how
>the data is handled is driver dependent and can generally be transferred
>from user space to device without copying.

I was not implying that a rread() call would be used to read directly
from a device driver.  In particular, I'm interested in knowing how
such a call might help reading from a socket, for example, that has
several layers of networking protcols below it.  Down at the lowest
levels of the protocol stack, the network interface driver needs to
have some place to put the data it has just received from the
network.   A typical implementation will allocate a system buffer (e.g.
a BSD 'mbuf'), copy the data into it and pass this buffer up to the
upper layers of the kernel where it gets copied again into the buffer
that was specified by the user's read() call.  A rread() call (if I
understand it correctly) would skip the last copy and return to the
user the address of the mbuf.  Avoiding data copies is very important
to the performance of network protocols.  The hard part is how to make
the low level drivers copy data directly into a user's buffer before
the protocol processing has taken place that tells the kernel to what
user the packet is directed.

Nobody has replied yet that has experience with the Arix rread() call.  I
did get one reply that suggested looking at the POSIS aread() call if
anyone is interested:

Someone else writes:
> I would say that a better performance enhancement is the POSIX 1003.4 
> Asynchronous I/O features. Rather than let the OS return the pointer to
> the data the application "posts a read" via aread() that contains a 
> completion function that is called when the I/O is completed. This way
>  the OS can keep the users buffer and do I/O directly into it. It works the
> same way with awrite(). This avoids the rfree() call.

Thanks for the replies.
-- 
Ron Holt	ron@Eyring.COM  uunet!lanai!ron
Eyring Inc.	+1 801-375-2434 x434