FCP Out of Order Data Delivery

Witalka, Jerome J [RV] jjw1 at PO9.RV.unisys.com
Thu Dec 22 09:36:00 PST 1994

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 

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
>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, 
>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.

More information about the T10 mailing list