FCP Out of Order Data D
Jim McGrath
jmcgrath at qntm.com
Thu Dec 22 17:06:21 PST 1994
Reply to: RE>>FCP Out of Order Data Delivery
The profile should not allow things that the standard precludes - the correct
thing to do is focus on revising the standard. If the standard allows it,
then I
do not see any need for any mention in a profile. Profiles should be
directed
to telling us what is the minimum that must be done, but should not (and in
practice cannot) prevent people from adding legal functionality to their
products. And unles it is easy/cheap and/or really required by a lot of
people,
it should not be required (otherwise you end up with options and the
standards
mess all over again).
Jim
--------------------------------------
Date: 12/22/94 10:54 AM
To: Jim McGrath
From: Witalka, Jerome J [RV]
Bob,
Our scatter gather requirements include buffers that are on top of paging
and are both smaller than and greater than virtual address page sizes.
Scatter/gather requirements for paging also have to be supported. If we
only had to support paging boundaries, I believe we could probably implement
an acceptable hardware solution to the out of order problem, but
unfortunately this is not the case.
As I read the SCSI 3 Primary Command Set document, the EMDP bit is only
valid for SIP. It states "The EMDP bit shall be zero for all devices except
those using the SCS-3 Interlocked Protocol (SIP)". This is interesting in
that a state of zero for this bit means that the Target is not allowed to
send the Modify Data Pointers message. I would have thought that this bit
would have been defined as a Disable Modify Data Pointers (DMDP) such that
the default zero setting would be to allow the Modify Data Pointers Message
if this is the most common Target implementation. If it is not the most
common implementation, then it would appear to me that it is even more
important that it be supported by FCP.
I would be more than satisfied if the EMDP bit were supported by FCP. Would
you be amenable to a change of wording to the SCSI 3 Primary command set
that would allow the EMDP bit to control Data order in separate data
sequences?
I would obviously like to see the FCP profile at least support the bit as
"optional Support" for Targets. Is the goal of the FCP profiles to supply a
minimum set of characteristics that will ensure interoperabilty throughout
the entire FCP marketplace or just attempt to address the "Workstation"
marketplace? If it is the former, I believe that optional support for the
EMDP should be included because we can't operate without it. If you only
intend to address the Workstation marketplace, then you obviously do not
need to consider our requirements. Support of EMDP is more important to us
than support of the Link bit since his is an issue in all of our
applications. The Link bit is only used in our multi host applications.
Jerry Witalka M.S. 4873 EMail:jjw1 at po9.rv.unisys.com
Unisys Corporation Voice: 612-635-7958
P.O. Box 64942
St. Paul, MN 55164-094
----------
>From: Bob.Snively
>To: Bob.Snively; fibre-channel-ext; scsi-request; jjw1
>Cc: kge3; let2; PDougherty; rhs1
>Subject: Re: FCP Out of Order Data Delivery
>Date: Wednesday, December 21, 1994 3:15PM
>
>
>One of the reasons that we (Sun) are not personally worried about this
>function
>is that our I/O Bus (IEEE 1496, SBus) uses virtual addresses in
>its DMA function, making scatter-gather mostly unnecessary or automatic.
>For our Fibre Channel array subsystem, out of order delivery is routine,
but
>typically on large blocks and on disk block boundaries.
>
>The other reason I am not worried about this function is that
>the EMDP bit could be used unchanged to manage this special case. Phrased
>another way, it is not an FCP problem, but rather a choice to
>implement the EMDP bit.
>
>I believe that the equivalence between Modify Data Pointers and
>the data descriptor is already well documented in section 7.2.1 on page 28
>of FCP Revision 10.
>
>Note that none of the Profiles address this question and would probably
>resist the requirement of implementing this additional function.
>
>Bob
>
>
>
>---
>
>
>
More information about the T10
mailing list