FCP Out of Order Data D
Witalka, Jerome J [RV]
jjw1 at PO9.RV.unisys.com
Fri Dec 23 07:36:00 PST 1994
Perhaps I was not clear enough. My main concern is modification of the
standards to add the functionality I believe we require. I do have a
secondary desire to change the profile to also call out this functionality
as optional but only if the standards are changed. I did request the Out of
Order functionality be added in the Optional category as opposed to
required. As I read them, the profiles do not make it illegal to add any
functions specified in the standards, but only specify the subset that will
guarantee interoperability.
Jerry
----------
>From: Jim McGrath
>To: Bob.Snively; fibre-channel-ext; jjw1; scsi-request
>Cc: kge3; let2; PDougherty; rhs1
>Subject: Re: FCP Out of Order Data D
>Date: Thursday, December 22, 1994 5:06PM
>
> 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