[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