RE: iSCSI: padding on intermediate sequences

[Eddy Quicksall <Eddy_Quicksall@ivivity.com>]

Maybe I didn't say something right. Here is what I meant:
 
I-T Read CDB of 1024 bytes
T-I Data-In with 513 bytes and F bit set. So, pad is 3 bytes. I don't like
pad here.
T-I Data-In with 511 bytes and F bit set. So, pad is 1 byte. This is the
only place I would like to see pad.
 
Since the F bit ends a sequence and since a transfer can have several
sequences, the spec allows each sequence to have pad. It is a problem for
the HW guys to deal with pad except at the end of the whole transfer.
 
Eddy

-----Original Message-----
From: Anshul Chadda [mailto:anshul.chadda@trebia.com]
Sent: Tuesday, March 26, 2002 5:25 PM
To: Sukha Ghosh; 'Robert D. Russell'; Eddy Quicksall
Cc: ips@ece. cmu. edu (E-mail)
Subject: Re: iSCSI: padding on intermediate sequences


suppose there is a requirement that a Data-In PDU with F-bit set (denoting
just end of sequence and not last data-in pdu for the command) have real
data (no pad bytes) in its last 4 byte word.

Now the target has to keep track of data over sequences. if a target doesn't
have enough real data to fill the last data-in pdu (in a sequence) to
integer number of 4 byte words, then it has to wait (don't know for how
long) for data that might belong to next sequence. this will increase the
work for target, won't it? and it will break the concept of sequences too as
we want the sequences to be independent of each other and not wait for each
other.

hope i got the question correct!!

Anshul

----- Original Message -----
From: "Sukha Ghosh" <sukha_ghosh@ivivity.com>
To: "'Robert D. Russell'" <rdr@io.iol.unh.edu>; "Eddy Quicksall"
<Eddy_Quicksall@ivivity.com>
Cc: "ips@ece. cmu. edu (E-mail)" <ips@ece.cmu.edu>
Sent: Tuesday, March 26, 2002 3:40 PM
Subject: RE: iSCSI: padding on intermediate sequences


> Just to clarify,
>
> What Eddy (please correct me if I am wrong) is asking is that if a Data-in
> response is multiple sequences of Data-In PDUs then the ending Data in
PDUs
> (F = 1)of intermediate sequences must also follow the 4-byte alignment
rule
> with pure data payload no padding. This means that only the last data-in
PDU
> can have padding, if necessary.
>
> -----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
> >