[Rdma-developers] RE: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

[Michael Krause]

At 09:29 AM 5/26/2005, Talpey, Thomas wrote:
>At 11:49 AM 5/26/2005, Bob Woodruff wrote:
> >Finally, until there is some consensus about allowing TCP offload in Linux,
> >I see no need to start to hack up the InfiniBand stack to support iWarp.
>
>It is not a requirement that TCP offload be supported in order to
>support iWARP. Upper layers which don't perform an rdma-upgrade
>(e.g. NFSv3/RDMA) don't even care about "speaking sockets".

TOE != Sockets.  TOE is simply the TCP/IP protocol stack that is off-loaded 
for any TCP-based application / sub-system to use.

>And I believe a Connection Manager can and should address this for the 
>ones that do. Tying iWARP to the TOE albatross furthers nothing.

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.

>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).

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.

>Do we have solid justification to add more? NFS/RDMA says "no".

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.  :)


* Feel free to ignore the following *

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.

Regards,

Mike 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20050526/079eb994/attachment.html>