<br><font size=2 face="sans-serif">Sukanta,</font>
<br>
<br><font size=2 face="sans-serif">without touching any TOE issues (this
question is about RDMA, right?), after</font>
<br><font size=2 face="sans-serif">transforming a TCP connection into RDMA
mode and using an RDMA API,</font>
<br><font size=2 face="sans-serif">the socket file descriptor is not longer
to be used for communication.</font>
<br><font size=2 face="sans-serif">In fact, on some implementations the
stream socket resources will</font>
<br><font size=2 face="sans-serif">even get released. That is, if the socket
was the direct consumer</font>
<br><font size=2 face="sans-serif">of the TCP stream, then now it is RDMAP/DDP/MPA.</font>
<br><font size=2 face="sans-serif">RDMA APIs such as IT-API defining a
specific call to convert a socket based</font>
<br><font size=2 face="sans-serif">connection into RDMA mode (e.g., it_socket_convert()).</font>
<br><font size=2 face="sans-serif">Other consumers may directly start via
an RDMA API, never</font>
<br><font size=2 face="sans-serif">opening a consumer controlled socket.</font>
<br>
<br><font size=2 face="sans-serif">So, in RDMA mode, communication will
happen via the RDMA API. At this</font>
<br><font size=2 face="sans-serif">stage, the kernel still have to keep
completely in its hands the</font>
<br><font size=2 face="sans-serif">synchronisation of state information
related to that offloaded</font>
<br><font size=2 face="sans-serif">connection(s) with the host stack (it
would have to protect the</font>
<br><font size=2 face="sans-serif">local port used by the offloaded connection
for example, others</font>
<br><font size=2 face="sans-serif">are routing, ARP, SNMP...), but it is
not involved at the data path.</font>
<br>
<br><font size=2 face="sans-serif">With respect to the kernel based TCP
stack, what is not needed is</font>
<br><font size=2 face="sans-serif">a hack into the stack and scatter/gather
state information of the live</font>
<br><font size=2 face="sans-serif">TCP connection between kernel and RNIC,
but to find one clean interface</font>
<br><font size=2 face="sans-serif">to transfer state information out of
that stack and to the RNIC.</font>
<br>
<br>
<br><font size=2 face="sans-serif">With limited benefit, one could of course
also implement native </font>
<br><font size=2 face="sans-serif">sockets over RDMA, where an in-kernel
midlayer on top of kernel</font>
<br><font size=2 face="sans-serif">RDMA Verbs is doing the translation
between send(), receive() to </font>
<br><font size=2 face="sans-serif">post_send, post_receive. But usage of
'true RDMA' operations</font>
<br><font size=2 face="sans-serif">like RDMA READ or WRITE might be limited,
and I don't see much value </font>
<br><font size=2 face="sans-serif">for the user here. One variety of this
approach with less limited</font>
<br><font size=2 face="sans-serif">access to RMDA benefits might be sockets
with extended RDMA </font>
<br><font size=2 face="sans-serif">semantics.</font>
<br>
<br><font size=2 face="sans-serif">Bernard.</font>
<br>
<br><font size=2><tt>rdma-developers-admin@lists.sourceforge.net wrote
on 27.05.2005 15:40:43:<br>
<br>
> Venkata,<br>
>    How will that work? If the RNIC offloads RDMA and<br>
> TCP completely from the Operating System and does not<br>
> share any state information then the application<br>
> running on the host will never be in the position to<br>
> utilize the socket interface to use the communication<br>
> logic to send and receive data between the remote node<br>
> and itself. Some information needs to be shared. How<br>
> much of it and what exactly needs to be shared is the<br>
> question.<br>
> <br>
> Thanks<br>
> SG<br>
> <br>
> --- Venkata Jagana <jagana@us.ibm.com> wrote:<br>
> > <br>
> > <br>
> > <br>
> > <br>
> > <br>
> > <br>
> > rdma-developers-admin@lists.sourceforge.net wrote on<br>
> > 05/25/2005 09:47:00<br>
> > PM:<br>
> > <br>
> > > Venkata,<br>
> > > Interesting coincidence: I was talking with<br>
> > someone (at HP) today<br>
> > > who knows substantially more than I do about<br>
> > RNICs.<br>
> > > They indicated RNICs need to manage TCP state on<br>
> > the card from userspace.<br>
> > > I suspect that's only possible through a private<br>
> > interface<br>
> > > (e.g. ioctl() or /proc) or the non-existant (in<br>
> > kernel.org)<br>
> > > TOE implementation. Is this correct?<br>
> > ><br>
> > <br>
> > Not correct.<br>
> > <br>
> > Since RNICs are offloaded adapters with RDMA<br>
> > protocols layered on<br>
> > top of TCP stack, they do maintain the TCP state<br>
> > internally but<br>
> > it does not expose to the host. RNIC expose only<br>
> > RNIC Verbs interface<br>
> > to the host bot not TOE interface.<br>
> > <br>
> > Thanks<br>
> > Venkat<br>
> > <br>
> > ><br>
> > > hth,<br>
> > > grant<br>
> > ><br>
> > ><br>
> > ><br>
> ><br>
> -------------------------------------------------------<br>
> > > SF.Net email is sponsored by: GoToMeeting - the<br>
> > easiest way to<br>
> > collaborate<br>
> > > online with coworkers and clients while avoiding<br>
> > the high cost of travel<br>
> > and<br>
> > > communications. There is no equipment to buy and<br>
> > you can meet as often as<br>
> > > you want. Try it<br>
> ><br>
> free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click<br>
> > > _______________________________________________<br>
> > > Rdma-developers mailing list<br>
> > > Rdma-developers@lists.sourceforge.net<br>
> > > https://lists.sourceforge.net/lists/listinfo/rdma-developers<br>
> <br>
> __________________________________________________<br>
> Do You Yahoo!?<br>
> Tired of spam?  Yahoo! Mail has the best spam protection around
<br>
> http://mail.yahoo.com <br>
> <br>
> <br>
> -------------------------------------------------------<br>
> This SF.Net email is sponsored by Yahoo.<br>
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!<br>
> Search APIs Find out how you can build Yahoo! directly into your own<br>
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005<br>
> _______________________________________________<br>
> Rdma-developers mailing list<br>
> Rdma-developers@lists.sourceforge.net<br>
> https://lists.sourceforge.net/lists/listinfo/rdma-developers<br>
</tt></font>