RE: sector alignment for DataOut PDUs?

[Robert Snively <rsnively@Brocade.COM>]

> > There has always been a feeling that it was nice to do things
> > on convenient boundaries, including memory page boundaries and
> > device physical block boundaries, but SCSI has long since 
> > elected to perform any operation on almost any boundary.  
> SCSI drives
> > and related operating systems have commonly used block sizes of 512
> > bytes and 520 bytes and less commonly of other values.  
> > 
> > The only requirement we were able to enforce in previous
> > SCSI protocols is that all but the last PDU of a transfer
> > were required to be on 4 byte boundaries.  We were also
> > able to enforce the maximum values and a requirement that
> > the transferred data count exactly match the requested byte
> > count.
> 
> I don't see that last point.  Certainly not for unsolicited data --
> and for R2T I can find no stated requirement to send exactly the
> requested count either.  Or did you mean the total for the entire
> operation as opposed to the individual bursts?
>  

I haven't reviewed all of iSCSI's rules with respect to this
particular issue.  There appears to be an assumption of 
non-congested processor-sized buffers that allow unsolicited
write data transfer.  That may be a convenient assumption for
some devices, but a problem for those that want more control
of their buffering.  In general, the requests for write data 
are part of the logical unit's write buffer management
and data striping management.  If you don't supply
exactly what is asked for, you foul up the buffer management of the
target, sometimes causing pathological performance problems.

> > I would strongly suggest that you not bother to enforce any
> > other boundary restrictions.
> > 
> > I believe Eddy was right when he asked:
> > 
> > 	Given that the TCP issues of reassembly 
> > 	are so much more complicated than
> > 	the concatenation issues necessary for 
> > 	target data alignment, is there
> > 	really a problem here?
> > 
> > My answer to him would be, no, there is not a problem.
> 
> I answered it before when Eddy said that, but I'll summarize it again:
> I'm not talking about a problem, I'm talking about an opportunity for
> simplifying the target and making it more efficient.
> 
> Given alignment, each iSCSI PDU that carries data can be sent to disk
> by itself, because it corresponds exactly to one or more disk blocks.
> Without alignment, doing writes when the data arrives is still
> possible, but it clearly adds complexity because PDU boundaries don't
> match disk block boundaries.
> 
> I made the proposal because it clearly helps the target and appears to
> add no significant burden on the initiator.  The feedback to date
> indicates that this is indeed the case.
> 
> Are you saying "I don't care one way or the other" or are you saying
> "I feel this is a bad idea because it creates problems you haven't
> thought of"?  I'm reading your comment as the former; if you meant the
> latter, could you elaborate?

I think I am saying that I care, and that it is an idea that
will trap you into limiting simplifications.  In general, the 
initiator's data flow engine has no knowledge of the logical 
unit's physical block structure.  In addition, the page structure
from which you are obtaining data in the host will usually have boundaries
that are unrelated to the logical unit's physical block structure.
While it is perfectly possible to align PDU's with blocks, it
requires SCSI ULP information to be forced in to the lower level
data transfer hardware.  This is a significant inconvenience and
will cost performance and/or complexity.  Note that the blocks
in a logical unit are not all required to be the same size, and in
tape drives and some optical devices are typically not the same size.

I still think it is best for the logical unit to ask for what it wants,
then expect to get it.  The logical unit is the only device in
the system that really knows what it needs and when it needs it.
That is one of the important SCSI principles, allowing the logical unit
to take over all the media dependent functions from the initiator
and the host programming.