RE: New List: rdma@cisco.com: to discuss RDMA

["Grun, Paul" <paul.grun@intel.com>]

Interesting point of view...if the target end cannot count on the service
being available at the initiator end, it does little good.

InfiniBand, which has an RDMA mechanism, ran into a similar problem.  The
solution was asymmetric requirements; requirements placed on the host end
permitted less latitude than those placed on the target end.  The result is
a set of services upon which the target end knows it can rely.

Paul Grun                                              
Intel Corporation - Enterprise Platform Group
(503) 677-6768 - paul.grun@intel.com <mailto:paul.grun@intel.com> 


> -----Original Message-----
> From: Stephen Bailey [mailto:steph@cs.uchicago.edu]
> Sent: Thursday, September 28, 2000 2:23 PM
> To: ips@ece.cmu.edu
> Subject: Re: New List: rdma@cisco.com: to discuss RDMA 
> 
> 
> > However, I would support structuring the spec so that an RDMA
> > transport mechanism could be used underneath (I guess that's
> > motherhood).
> 
> Not necessarily.
> 
> You have to ask the implementors (particularly the hardware
> implementors), what sort of optional RDMA proposal they'd be happy
> with.  My answer is none.  It's mandatory or not at all.
> 
> The reason for using RDMA is to make the implementation of iSCSI
> easier in hardware.  If there are implementations which do not support
> the RDMA protocol, then your hardware implementation will have to
> support both the `easy path' (using RDMA) and the `hard path' (no
> RDMA).  If you have to implement the hard path anyway, there's no
> point in implementing the easy path.
> 
> The argument that you could make the hard path infrequent and
> implement it in software doesn't wash in this case.  It just takes one
> implementation that doesn't do RDMA to slow your system to a crawl,
> and the competitor who only implemented the non-RDMA path makes you
> look like a fool.
> 
> Fundamentally, RDMA has to be either adopted or punted.  Of course,
> I'm happy to have somebody prove this statement wrong.
> 
> Steph
>