RE: Framing Discussion

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

At 04:58 PM 12/20/2000 -0800, Douglas Otis wrote:

>problem of the block size being less than the page size.  Unless the SCSI
>application is forced to allocate in pages and you have a means to force the
>alignment of these blocks as they are delivered by the network, then this
>MMU technique is not available.

Many file systems allocate in nice multiple 4KB quantities making much of 
this fairly straight to implement and for partials these are either placed 
in a multiple 4KB buffer or these tend to align on power of 2 quantities 
buffers so the performance impacts are mitigated.

>You are suggesting that you use a standard TCP, find the PDU, process the
>iSCSI headers, place the data according to the tag within the iSCSI header,
>and because this process is located on the network adapter, it does not
>impact TCP.  I think I understand the logic.  As you expect the PDU to be
>"often" segment aligned, framing is not an issue.

Correct.

> > A zero-copy TCP is a content directed placement of the data.  Content
> > directed placement implicitly implies header / data split including the
> > iSCSI protocol headers.  Don't see what the problem is.
>
>Not at all.  The content of the payload does not impact the placement with
>Zero Copy TCP.  Here you expand the definition of this interface to now
>include iSCSI.  Rather than using TCP as the boundary between the adapter
>and the system, iSCSI is now such a boundary.

For a completely off-loaded solution, this is correct.  It is possible to 
only off-load the TCP portion and provide a scatter operation where the 
iSCSI header is targeted to a different control set of buffers and the data 
goes the appropriate data buffers - this is done in many of today's 
implementations so the logic is well-understood.

>Fine, but you really should not call this part of TCP.  It is not.  You
>should call it an iSCSI adapter interface.  If you wish such an interface to
>be application specific, so will its interface.  Clearly SCSI dictates a
>different interface to that of TCP.  If you advocate the placement of the
>application on the adapter, then you are no longer discussing TCP.  You are
>discussing the back-end of a full or partial processing of iSCSI.  TCP is
>hidden within this application running on the adapter.  I had advocated
>using a pointer to an application routine to serve this function of placing
>the application on the adapter and should the value be less than 1024, it
>would indicate a pre-defined IANA designator for such an embedded
>application.  Perhaps the value of 1 could indicate a normal IP stack as the
>application as you bind the application to the port.  If this is the desire
>of the work group, as it seems to be, then declaring details of the
>application adapter interface is the next step.  What group makes adapters?

InfiniBand is looking to standardize the interface to InfiniBand-based TOE 
(TCP Off-load Engine) endnodes so that  a well-defined wire protocol can be 
created for all IHVs to implement above the InfiniBand transport 
protocol.  I think there might be some benefit to do the same thing for 
iSCSI as for TOE in an appropriate forum while allowing this workgroup to 
proceed with the iSCSI definition which defines the operational model and 
wire protocol being used.  In fact, if the iSCSI workgroup sets up some 
basic rules as outlined in another response from me today or along the 
lines of the various RDMA proposals, then the wire protocol defined by the 
iSCSI workgroup in essence defines much of this needed interface.  Need to 
think about what else if anything might be needed.

Mike