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

["Jim Williams" <jimw@giganet.com>]

David Black wrote:

>And this illuminates the design tradeoff that may motivate RDMA.  If
>one only wants to accelerate one protocol (SCSI/FCP in the above
>example) then having hardware understand its headers and doing
>the DMA on that basis is a fairly obvious way to go - HBAs for both
>parallel SCSI and Fibre Channel (SCSI/FCP) do this.  RDMA may be
>interesting if there are multiple protocols involved, and there are
>engineering concerns that lead to not wanting to implement hardware
>support for all of them.
>
>From an iSCSI viewpoint, I don't see iSCSI by itself as being sufficient
>to motivate a protocol-independent RDMA - an iSCSI HBA could understand
>the iSCSI headers and interact with DMA in the same fashion as existing
>HBAs.  The task before those interested in RDMA is to identify a set
>of protocols for which a common RDMA mechanism makes sense from
>an engineering standpoint.

I think this is a good summary of the situation.  I agree with the above.

Stephen Bailey wrote:

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


As a hardware implementor, I tend to agree with the above: manditory
or not at all.  (Although I am still open to specific proposals that
might argue to the contrary.)