[Stgt-devel] uSpace Transport Patch
Tom Tucker
tom
Tue Aug 22 17:17:09 CEST 2006
> >
[...snip...]
> > Yes, I'm working on that now, I just didn't want to get too far down a
> > road that lead somewhere we didn't want to go. Basically, the iSER code
> > is implemented in the kernel. The user-mode interface is a file
> > descriptor (used for polling), and a either a) set of methods
> > implemented via read/write for listening for, accepting and
> > send/receiving, or b) using the netlink interface. I'm leaning towards
> > the former actually.
>
> The previous patch uses the latter approach (similar to open-iscsi),
> right? So, could you explain the formaer approach a bit further?
- The existing netlink messages stay the way they are. That is, we don't
add any new ones.
- The iSER kernel driver has a character device file in
/sys/class/iscsi_transport/iscsi_iser_tgt/listen. When the client
(istgt) opens this file, it receives a file descriptor that refers
to an in-kernel rdma connection id. The iut binds to a specific
address and port by write-ing the desired sockaddr and port number.
The return value from the write is the result of the bind.
- A poll of this file descriptor will return an revent when there is an
inbound connection request.
- The iut_ reads from the listen_fd to receive the fd for the
new connection along with the local and remote sockaddr and len.
- The iut continues with login by calling 'read' and 'write' on the new
fd to send and receive data login messages. Likewise, a poll of the
fd will return an revent when there is data to read and/or can-write-more.
- The iut moves the transport to the kernel just like it does today by
sending a netlink message to the transport.
This approach allows us to leverage the open/read/write/poll semantics of
an fd without muxing it all over a netlink socket.
Tom
More information about the stgt
mailing list