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