Subject: Re: sctp_peeloff()

From: Kacheong Poon <[email-masked]>
Date: Wed, 10 Dec 2003 02:14:16 -0800

Caitlin Bestler wrote:

> There is a major benefit to being able to use stream
> specific buffers when reading.
> 
> But with the sockets API that has to be weighed against
> the overhead of using poll/select to find out which
> stream has supplied the buffer.
> 
> If you migrate to more of an asynchronous interface,
> I believe the ideal is to allow receive buffers to be
> pre-posted on a per-stream basis, but to receive the
> completions on a consolidated socket. In terms of a
> VIA/IB/RDMA style interface, each stream has its own
> Send and Receive Queues, but the  entire association
> has a single Completion Queue.

One catch is that this kind of schemes, event completion
queue, normally align with file descriptor.  This means
that after buffers are pre-posted to a socket, the
completion event is delivered to the same socket.  The
reason is simply that the framework is also used by
other file descriptor, not just socket.  I agree that
different implementations may have different architectures.

Can people comment on whether the above file descriptor
alignment is common on different platforms' event completion
framework?  If this is true, then peeling off a stream from
a socket fits what you mentioned above.

> Personally, I believe there is more value in trying
> to add that type of functionality to the API than in
> running a classic synchronous socket for each stream.
> However, I would agree that there are uses for both.
> 
> In particular, having to provide the target buffer
> for a read *before* knowing what stream the next
> message is for has always struck me as awkward.
> 
> 

-- 

						K. Poon.
						[email-masked]