[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: iSCSI: padding on intermediate sequences
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,
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
>