RE: VI (Was: Avoiding deadlock in iSCSI)

[Stephen Byan <Stephen.Byan@quantum.com>]

Douglas Otis [mailto:dotis@sanlight.net] wrote:

> Charles,
> 
> Depending on the capabilities of the Net-SCSI adapter, such 
> direct copies
> would be possible without resorting to VI.  Not using VI but 
> allowing direct
> placement also provides lower overhead and a safer system as 
> pointers going
> astray due to a muddled target or bit rot is not a concern.  
> SAM requires
> buffers to be in place prior to issuing the request.  These 
> buffers are at
> the client which is where VI becomes useful.  Unless both ends of this
> communication becomes VI, you have not provided a meaningful solution.

It may be better/more efficient/easier/whatever to implement iSCSI directly
over TCP rather than over VI over TCP. My point was that in return for the
pain, we can leverage the utility of the RDMA hardware assists, since the
assists would be encapsulated in the VI layer, rather than intimately part
of the iSCSI protocol. Consequently the RDMA hardware could be reused to
accelerate other new protocols, as well as cluster message passing.

I think an enlarged market for the hardware is important in order to ensure
the success of iSCSI.  iSCSI depends on getting RDMA hardware acceleration
NICs into the servers. Consider two product scenarios:

1) a NIC with RDMA hardware acceleration for iSCSI.
2) a NIC with RDMA hardware acceleration for iSCSI, DAFS, MPI, Oracle
Parallel Server, DB2 extended edition, and which is open to future
applications. 

Which product do you think would be the easiest to sell to an end-user
customer?

> Adding VI modifies TCP.  

I don't believe draft-dicecco-vitcp-00.txt modifies TCP in any way.

However, I do think the proposed TCP Message Boundary Option would be useful
in order to optimize the implementation of RDMA in either iSCSI or in
VI/TCP.

Regards,
-Steve

Steve Byan
<stephen.byan@quantum.com>
Design Engineer
MS 1-3/E23
333 South Street
Shrewsbury, MA 01545
(508)770-3414
fax: (508)770-2604