RE: Framing Discussion

[Michael Krause <krause@cup.hp.com>]

At 08:28 AM 12/20/2000 -0800, Y P Cheng wrote:
> > >Why are they not interchangeable ? This is an
> > >assumption not stated anywhere.  Is there
> > >a list of other assumptions that is documented ?
> > >
> > Typically, the original data buffer is with the application that
> > made the SCSI READ request - and this buffer may not have been
> > allocated with the constraints that should be ready for a simple
> > swapping. Assuming that the constraints are met, it would require
> > VM page flipping, which is considered to be an implementation hack.
>
>I think you are mixing TCP and SCSI implementations.  The SCSI semantic
>requires the buffers of a READ pre-allocated and locked.  For TCP, the
>incoming byte stream enters a socket can be buffered waiting for a READ
>command.

Since the discussion is focused on iSCSI, it is fair to assume that the 
data can be targeted to the correct buffer and that this buffer was 
advertised as the target for the operation.


> > A protocol level solution to locate the buffer and its offset for
> > the incoming TCP segment is probably a better thing to have.
>
>I guess by protocol you are referring to the TCP/RDMA or iSCSI framing that
>allow the iSCSI data in a TCP segment to be quickly moved to the application
>buffers, PRE-ALLOCATED, without in-order arriving.

One does not require RDMA / framing support to implement this capability 
since a local table look-up can be used to provide the SCSI op mapping to 
the target buffer.  RDMA / framing simplify this look-up as the headers 
carry the requisite information that simplifies the data placement lookup / 
verification process.  There is still a local table maintained for RDMA 
with the address-to-VA-physical mapping and access rights verification 
being performed which is slightly simpler and more compact to store than 
tracking each SCSI buffer's attributes and mapping the incoming data to the 
target buffer.

Mike