SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI: padding on intermediate sequences



    Apparently FC had to make this restriction (see EMAIL from Robert Snively [rsnively@brocade.com] dated 3/27). We should consider that as a basis for discussion.
     
    I have quoted Bob below:
     
    >Since there is no requirement by the SCSI ULP to say anything about data until
    >the SCSI Status has been presented, there is no need to concern ourselves with
    >device dependent burst boundaries.  We can make the boundaries convenient
    >for the technology.  In FCP, all bursts were required to begin on a
    >4-byte boundary, and all except the last to end on a 4-byte boundary.  This
    >simplified DMA and segmentation/reassembly mechanisms
    >in all hardware paths.  Looking at the TCP/IP formats, I see a similar
    >bias toward 4-byte structures, which implies that the same rule would be
    >a constructive addition to the document.
    >
    >This simply prohibited the target from asking for a number of intermediate
    >bytes that was not a multiple of 4.
    >
    >The folks using odd byte block counts had to manage the buffers in
    >a manner appropriate to such behaviors.  Practically, I do not believe that
    >there were many such devices, nor was this a burden to any devices that did
    >support such behavior.
    >
    >Bob
     
    Eddy

     -----Original Message-----
    From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    Sent: Wednesday, March 27, 2002 3:03 AM
    To: Eddy Quicksall
    Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu
    Subject: RE: iSCSI: padding on intermediate sequences


    Eddy,

    Now that we understand better you issue here are some reasons why we may not want to do what you propose:
    • the target may ask for a number of bytes that is not a multiple of 4 (should we outlaw this? I don't think we want)
    • there might be devices that require/generate in "bursts" that are not multiples of 4


      I think that we avoided abuse by what we have and we should leave further optimization to the implementer for specific devices.

      Julo


      Eddy Quicksall <Eddy_Quicksall@ivivity.com>
      Sent by: owner-ips@ece.cmu.edu

      27-03-02 02:41
      Please respond to Eddy Quicksall

             
              To:        "ips@ece. cmu. edu (E-mail)" <ips@ece.cmu.edu>
              cc:        
              Subject:        RE: iSCSI: padding on intermediate sequences

             


      It is the sequences I am speaking of, not the segments. The current wording
      of the spec would allow you to send sequences with padding in each sequence
      (the segments within the sequence are ok because they can't have padding).
      But if a transfer is made up of several sequences then it is more work for
      the hardware if intermediate sequences were allowed to have arbitrary pad
      bytes.

      And there is no good reason (that I am aware of) that intermediate sequences
      could not just be pure data.

      Now, if there is a reason, then we should come up with a scheme that allows
      one party to "just say no". One possibility is that if DataInOrder=yes, then
      padding would not be allowed except in the sequence that represents the last
      portion of the transfer.

      If that is objectionable, then we should have a new key
      (PaddingOnlyInLastSequenceOfTotalTransfer=yes). :-)

      Eddy

      -----Original Message-----
      From: Robert D. Russell [mailto:rdr@io.iol.unh.edu]
      Sent: Tuesday, March 26, 2002 2:48 PM
      To: Eddy Quicksall
      Cc: ips@ece. cmu. edu (E-mail)
      Subject: Re: iSCSI: padding on intermediate sequences


      Eddy:

      I may not be understanding you correctly, but the
      words in section 9.7.7 I believe mean that these data
      segments should contain an integer number of 4 byte words
      of data, not arbitrary "pad" bytes.  If the data segment
      length is a multiple of 4 then there will be NO pad bytes.

      There seems to be confusion over your use of "pad"
      and the standard's use of "pad".  Would you please clarify?

      Thanks,
      Bob


      On Tue, 26 Mar 2002, Eddy Quicksall wrote:

      > Section 9.7.7 says:
      >
      > The Data Segments of Data-in and Data-out PDUs SHOULD be filled to the
      > integer number of 4 byte words (real payload) unless the F bit is set
      > to 1.
      >
      > This allows one to pad intermediate sequences of a transfer. But, there
      are
      > reasons why padding on intermediate sequences within a transfer can make
      > life difficult.
      >
      > Can we forbid padding on all but the last PDU for the transfer? If that is
      > objectionable, could we forbid padding on all but the last PDU of a
      transfer
      > if DataInOrder=yes.
      >
      > Eddy
      >




Home

Last updated: Thu Mar 28 12:18:17 2002
9364 messages in chronological order