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

["TALBOTT,GLENN (HP-Roseville,ex1)" <glenn_talbott@hp.com>]

Julo,

Sorry to take so long to get back to you on this question, a week of
vacation makes it close to impossible to get caught up.

To answer your question: I see no difference between the RDMA READ and the
R2T (other than the fact that the RDMA READ passes some addressing
information rather than just a simple Ready indication). I think my point at
the time I said it was to forestall anyone thinking that both the RDMA READ
and the R2T needed to be sent.

Glenn

-----Original Message-----
From:	julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
Sent:	Sunday, October 01, 2000 1:14 AM
To:	ips@ece.cmu.edu
Subject:	RE: New List: rdma@cisco.com: to discuss RDMA



Just out of curiosity - what is the difference between an RDMA read-request
and the R2T you are trying to avoid?

Julo

"TALBOTT,GLENN (HP-Roseville,ex1)" <glenn_talbott@hp.com> on 28/09/2000
00:31:35

Please respond to "TALBOTT,GLENN (HP-Roseville,ex1)" <glenn_talbott@hp.com>

To:   "'csapuntz@cisco.com'" <csapuntz@cisco.com>
cc:   ips@ece.cmu.edu (bcc: Julian Satran/Haifa/IBM)
Subject:  RE: New List: rdma@cisco.com: to discuss RDMA




Costa, et al.,

I believe that specifying an RDMA mechanism for iSCSI is the right thing to
do.

RDMA (especially when combined with a frame recovery mechanism such as the
one described by Jim Williams) will enable iSCSI NIC implementers to
eliminate the massive on-card buffering and double processing required to
implement SACK in the face of long, fast, fat pipes. The NIC is able to
push
each inbound RDMA frame off into it's proper place in host memory while
waiting for the missing packet instead of buffering the receive stream
until
the missing packet is received to recover synchronization.

A general purpose RDMA and framing solution will benefit both iSCSI and
VI/TCP.

I do not believe that an RDMA mechanism should be mandatory for iSCSI.

Manufacturers of lower cost thin storage devices may opt to limit
applications to inside the data center, throw large amounts of off chip RAM
at the problem (possibly not constrained to PCI NIC form factors), or
accept
lower performance by not implementing SACK, rather than go to the expense
of
the added complexity that RDMA may add to an implementation.

I can see a future where iSCSI server initiators typically implement RDMA
and targets typically do not. Then SCSI reads are satisfied by the target
sending a sequence of RDMA writes to the initiator, and SCSI writes are
satisfied by the target sending a sequence of RDMA reads to the initiator.
This also eliminates the need for the target to send R2T. Each RDMA read is
an implicit R2T.

Glenn Talbott

> -----Original Message-----
> From: csapuntz@cisco.com [mailto:csapuntz@cisco.com]
> Sent: Wednesday, September 27, 2000 10:16 AM
> To: Jim Williams
> Cc: ips@ece.cmu.edu; csapuntz@cisco.com
> Subject: Re: New List: rdma@cisco.com: to discuss RDMA
>
>
>
> Does anybody on the list object to specifying an RDMA mechanism for
> use with iSCSI? Does anybody on the list object to mandating an RDMA
> mechanism? Please include your reasons.
>
> Current RDMA proposals:
> draft-csapuntz-tcprdma-00.txt
> draft-dicecco-vitcp-00.txt
>
> -Costa
>
> > Before going too far down this road, it is important to
> > understand if there is support for using an RDMA mechanism
> > as a basis for iSCSI.  Will the next draft of the iSCSI
> > protocol actually be based on an RDMA mechanism that
> > would be defined?  The answers to these questions and
> > the specific pros and cons need to be the driving
> > force behind the RDMA discussion.
>