On Apr 23, 2007, at 5:53 PM, Anders Persson wrote:
Hi Everyone,
I just published a design document for the kernel sockets interface
[1]. The document is short, so hopefully everyone will have time to
read it :) Any comments would be appreciated.
Anders
[1] http://www.opensolaris.org/os/project/kernel-sockets/files/
kernel-sockets.pdf
Anders,
Thanks for the pointer. I have been working through a new architecture
or refactoring of the kernel RPC services; as you know and allude to
in the above document, the NFS client and server rely heavily on
direct access (with minimal overhead) to the UDP and TCP stacks;
streams today -- ksockets going forward.
The ability to receive asynchronous notification of events is
a critical requirement for the kernel RPC services (today's and
the eventually for the refactored kernel RPC as well).
The refactored kernel RPC interfaces will themselves be
fundamentally asynchronous (very different than the traditional
RPC APIs.
Given that, I have just a few general questions.
Today, the NFS client and server, in support of RDMA transports
like Infiniband, will start with TCP connections and then
determine if RDMA is available on the interface used for
the connection. Most of this work is done at user-level
with a smaller set of code in the kernel for the final
setup. It would be helpful to enable the NFS client and
server to do this transition completely within the kernel.
This is a nice to have; not a requirement.
The kernel RPC interfaces use the streams timer mechanism to
timeout and close idle connections; again, a nice to have
but not a hard requirement. I should also mention that the
NFS server changes the receive buffer size/window size to
stop-down the client when it is not receiving data as quickly
as it is sending requests. Seems like that will be covered
with what you propose.
Finally, what additional thoughts do you have about the
event notification mechanism. Will it deliver multiple
events, simultaneously for a particular socket? Or will
it wait for one event delivery to be complete before
delivering the next. Would it be possible chain or provide
a list of events? If so, I would imagine that the consumer
of the interfaces would specify the desired behavior.
Spencer
_______________________________________________
networking-discuss mailing list
[email protected]
