<html>
<body>
<font size=3>At 09:29 AM 5/26/2005, Talpey, Thomas wrote:<br>
<blockquote type=cite class=cite cite="">At 11:49 AM 5/26/2005, Bob
Woodruff wrote:<br>
>Finally, until there is some consensus about allowing TCP offload in
Linux, <br>
>I see no need to start to hack up the InfiniBand stack to support
iWarp. <br><br>
It is not a requirement that TCP offload be supported in order to<br>
support iWARP. Upper layers which don't perform an rdma-upgrade<br>
(e.g. NFSv3/RDMA) don't even care about "speaking
sockets".</font></blockquote><br>
TOE != Sockets. TOE is simply the TCP/IP protocol stack that is
off-loaded for any TCP-based application / sub-system to use.<br><br>
<blockquote type=cite class=cite cite=""><font size=3>And I believe a
Connection Manager can and should address this for the ones that do.
Tying iWARP to the TOE albatross furthers
nothing.</font></blockquote><br>
iWARP != TOE though one uses an integrated TOE in a RNIC if you want
performance. Connection management is unique to IB as it is to
TCP. It must exist as a separate interface for subsystems to
use. Whether one can abstract a common API or just accept that IB
and TCP are different and call accordingly once understanding the
underlying hardware is debatable.<br><br>
<blockquote type=cite class=cite cite=""><font size=3>I completely agree
with your other point that a lower-layer cut-in is preferable to another
top-layer API. We already have APIs which provide transport-independent
RDMA services to existing upper layers (such as NFS/RDMA and iSER, coded
in fact to kDAPL). </font></blockquote><br>
kDAPL is being used by some sub-systems. One can argue that a verbs
interface is a cleaner way to get directly to the hardware without
requiring an intermediary API like DAPL (user or kernel). Caitlin
will provide some good counters why this isn't necessarily perfect.
Both sides have valid points in the debate. In the end, it is what
people implement that matter and whether that gets accepted by customers
in the end as good enough technology. Just because there are some
point-in-time implementations for NFS/RDMA and iSER does not mean that
kDAPL is the right or only answer. They are only what has been
implemented to date. If someone builds a better implementation
using another interface, then that could easily replace what is there
today. The RNIC PI or IB verbs interfaces articulate the intent of
those of us who created the verbs in the first place. We
intentionally left it open as to whether further abstraction was required
such as IT API or DAPL. We did intend for subsystems like MPI, SDP,
iSER, etc. to be able to use the verbs directly if desired. I think
many of us viewed IT API and DAPL as a potential point of abstraction to
insert other value-add functionality that should be transparent to the
applications but should not pollute the verbs, e.g. virtualization or
specific types of load balancing or fail-over.<br><br>
<blockquote type=cite class=cite cite=""><font size=3>Do we have solid
justification to add more? NFS/RDMA says
"no".</font></blockquote><br>
I don't believe any one person speaks for a given technology especially
in an open source world. In fact, I suspect you'll find a large
number of people who will disagree with this assertion as well.
:)<br><br>
<br>
* Feel free to ignore the following *<br><br>
I also find it unprofessional some of the diatribes that occur at times
on these reflectors. It would be more constructive if people
focused on technical issues instead just painting broad negative
statements. We all have opinions on how things should be
developed. Keeping things objective is much more
constructive. I always try to keep my responses focused on
whether I would appreciate such a response or whether the response tone /
language would be acceptable at my place of work. Colorful
language, unnecessary inflammatory statements, etc. result in people
loosing credibility and thus effectiveness in any environment. The
worse thing for any engineer / professional is to be simply written off
as a hot-head who is no longer being heard by any. <br><br>
Regards,<br><br>
<font size=3>Mike</font></body>
</html>