<html>
<body>
<font size=3>At 09:29 AM 5/27/2005, Grant Grundler wrote:<br>
<blockquote type=cite class=cite cite="">On Fri, May 27, 2005 at
07:24:44AM -0700, Michael Krause wrote:<br>
...<br>
> Again, Sockets is an application API and not how one communicates to
a TOE <br>
> or RDMA component.<br><br>
Mike,<br>
What address family is used to open a socket over iWARP? AF_INET?<br>
Or something else?</font></blockquote><br>
TCP = AF_INET. Address family != Sockets. Sockets is an API
that can operate over multiple address families. An application can
be coded to Sockets, IT API, DAPL, or a verbs interface like the RNIC
PI. It is a matter of choice as well as what is trying to be
accomplished. The RNIC PI is an acceptable interface for any
RDMA-focused ULP. There are pros / cons to using such a verbs
interface directly but I do not believe any one can deny that a
general-purpose verbs API is a good thing at the end of the day as it
works for the volume verbs definition. Whether one applies further
hardware semantics abstraction such as IT API / DAPL should be a choice
for the individual subsystem as there is no single right answer across
all subsystems. Attempting to force fit isn't practical.<br><br>
<blockquote type=cite class=cite cite=""><font size=3>I understand most
of what you wrote but am still missing one bit:<br>
How is the RNIC told what the peer IP is it should communicate
with?</font></blockquote><br>
The destination address (IB GID or IP) is derived from the CM
services. This is where the two interconnects differ in what is
required to physical inject a packet on the wire. This is why I
call it out as separate from the verbs interface and something that could
be abstracted to some extent but at the end of the day, really requires
the subsystem to understand the underlying fabric type to make some
intelligent choices. Given this effort is still nascent, most of
the issues beyond basic bootstrap have not really been discussed as
yet.<br><br>
<br><br>
<blockquote type=cite class=cite cite=""><font size=3>> The RNIC PI
has been proposed as an interface to the <br>
> RDMA functionality. The PI supports all of the iWARP and IB v
1.2 verbs.<br><br>
That's good. Folks from RDMA consortium will have to look at openib
implementations and see whats missing/wrong.<br>
Then submit proposals to fill in the gaps. I'm obviously not the first
one to say this.</font></blockquote><br>
There are two open source efforts. The question is whether to move
to a single effort (I tried to get this to occur before OpenIB was
formally launched but it seem to fall on deaf ears for TTM marketing
purposes) or whether to just coordinate on some of the basics. My
preference remains that the efforts remained strictly focused on the RDMA
infrastructure and interconnect-specific components and leave the ULP /
services as separate efforts who will make their own decisions on how
best to interface with the RDMA infrastructure.<br><br>
<blockquote type=cite class=cite cite=""><font size=3>I expect most of
the principals involved with openib.org do NOT have time to browse
through RNIC PI at this point. They are struggling to get openib.org
filled in sufficiently so it can go into a commercial distro (RH/SuSE
primarily).</font></blockquote><br>
Hence, why OpenRDMA needs to get source being developed to enable the
RNIC community. If people find value in the work, then people can
look at finding the right solution for both IB and iWARP when it makes
sense.<br><br>
<br>
<blockquote type=cite class=cite cite=""><font size=3>Revenue for them
comes from selling IB equipment. Having openib.org code in kernel.org is
a key enabler for getting<br>
into commercial distros. I expect the same is true for RNIC vendors
as well.<br><br>
RNIC Vendors (and related switch Vendors) will have to decide which path
is the right one for them to get the support into kernel.org. Several
openib.org people have suggested one (like I have). RNIC folks need to
listen and decide if the advice is good or not. If RNIC folks think they
know better, then please take another look at where openib.org is today
and where rdmaconsortium is.<br><br>
I'm certain openib.org would be dead now if policies and direction
changes had not made last year as demanded by several key linux
developers and "users" (Gov Labs).</blockquote><br>
Understood.<br><br>
Mike</font></body>
</html>