[Rdma-developers] Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMA APIs and ULPs for Linux

Caitlin Bestler caitlinb at siliquent.com
Fri May 27 10:35:17 PDT 2005


 

> -----Original Message-----
> From: Grant Grundler [mailto:iod00d at hp.com] 
> Sent: Friday, May 27, 2005 10:06 AM
> To: Caitlin Bestler
> Cc: Michael Krause; Sukanta ganguly; 
> rdma-developers at lists.sourceforge.net; openib-general at openib.org
> Subject: Re: [Rdma-developers] Re: [openib-general] OpenIB 
> and OpenRDMA: Convergence on common RDMA APIs and ULPs for Linux
> 
> On Fri, May 27, 2005 at 09:45:06AM -0700, Caitlin Bestler wrote:
> > I'd like to add that RNIC-PI is planning on explicitly 
> defining some 
> > of these "obvious" dependencies between the RDMA stack and 
> the primary 
> > IP stack. For example, the RDMA stack cannot maintain any 
> connection 
> > in a state that contradicts current IP stack routing. It 
> has to adapt 
> > or break the connection.
> 
> That's what I was just thinking. Could RNIC driver support 
> both existing linux NIC interfaces (e.g. use 
> ifconfig/ethtool) *and* openib RDMA interface?
> 
> Essentially that's what openib.org does today but uses 
> ib_ipoib driver to support TCP/IP communication.
> 
> Ie use an AF_INET socket to setup an RDMA connection like the 
> rdma_lat.c does:
> 	https://openib.org/svn/gen2/trunk/src/userspace/perftest/
> 
> Of course, I'm "blissfully ignorant" of how ugly that might 
> be in real world implementation of RNIC driver. Seems simple 
> in concept at least.
> 

For time-to-market reasons, and to avoid having to go hacking
deeply into the kernel from a driver, many or most existing
implementations require or at least prefer using TOE sockets.
It is much easier to extract the TCP state from a socket that
you already control than from the host stack.

But that is exactly the sort of limitation that integrating
with the kernel should eliminate. Given a stable interface
to "get TCP state" from a host controlled connection I can't
imagine why an RNIC vendor would not eagerly embrace it.




More information about the general mailing list