payload size (5/95 FC-AL Minutes)
stai at dt.wdc.com
Fri May 12 17:27:39 PDT 1995
OK, I am confused (nothing new, eh?-)... I was not at the meeting, so I
am afraid I must go by what I read in the minutes:
1. I thought that the 256 byte minimum payload referred to in FC-PH was
really the "lowest maximum". Payloads can always be smaller (what about
the last frame of a sequence that is not the multiple of a frame
size?). The limit establishes that a device must be able to receive at
least 256 as its max frame size. Right?
2. Is not the payload for FCP_CMND 32 bytes? If so, must we then also
bump it up to 256?
3. Now that we have gotten past THAT, we have this 256 byte upper limit
for sense data size, which has always been the case, all the way back
to SCSI-1. This should not be a surprise...? Apparently, the news now
is that someone has identified a use for all of it...
4. The issue on the actual size of FCP_RSP frames/sequences is not the
general size of payload that can be handled, it relates more to the
ability of the initiator and target to deal with "non-data" frames;
i.e., commands, status/sense, etc. Smaller entities are easier to route
between FC-2 and FC-4 than larger ones, in general. Efficient
implementations need to keep this stuff out of the main data path; I
know we all have experience in this from our SCSI days...
Therefore, I like the following for the profile:
* For GOOD status (Our Friend, the SCSI Status Byte ;-), the maximum
payload of FCP_RSP is required to be less than 128 bytes. Heck, I can't
see a reason for any more than 32 bytes, but I'll try and be easy. If
everyone could agree on 32 bytes, that would be great!
* For any other status, the recommended maximum payload for FCP_RSP is
128 bytes. If more is needed in some situations, that's fine. Don't
make a habit of it.
I gather from the minutes there wasn't a groundswell of demand for more
bytes of payload. Does my proposal meet the needs of SCC etc.?
western digital i/o products
stai at dt.wdc.com
> 13. FCP_RSP PAYLOAD LENGTH
> The question was raised that since the minimum payload length is now
> 256 bytes, what we should do with the FCP_RSP payload, which was
> limited in length to accomodate a 128-byte limit. The goal was to
> keep FCP_RSP a single-frame Sequence. The 128-byte limit for
> fabric-attach was to accomodate early Ancor implementations. Since
> Private Loops prohibit use of fabrics, the 256-byte limit was adopted
> to increase Read Exchange lengths and also accomodate LILP/LIRP frames
> in the future (which require more than 128 bytes of payload).
> Since FCP_RSP_INFO is now limited to 8 bytes in FCP, 12 bytes can be
> reclaimed and used for FCP_SNS_INFO (total of 96 bytes). However,
> this still falls short of the 256 bytes allowed by SPC Request Sense
> data (one byte of allocation length). Also, some array vendors may
> send back VU "layered" sense data which exceeds 96 bytes.
> Rather than increase the minimum RX data field size to 384 or 512
> bytes, it was decided that it should stay at 128 bytes with 96 bytes
> of sense data allowed, which should be enough for single-LUN, non-SCC
> devices. Proposals for the definition of hierarchical sense data
> within the context of SCC would be treated separately.
> Question: the profile still only provides a "partial" compliance to
> SPC by providing 96 instead of 256 bytes of sense information. Is
> this acceptable? If not, we may want to consider allowing Targets to
> send and requiring Initiators to be able to receive 512 byte frames,
> while still only requiring 256 byte frame reception by Targets.
More information about the T10