f_campbell at qlc.com
Thu Feb 27 14:08:54 PST 1997
* From the SCSI Reflector (scsi at symbios.com), posted by:
* Frank Campbell <f_campbell at qlc.com>
My comments/responses are embedded below.
DavidW at bangate.compaq.com wrote:
> Many of the things that you point out as concerns are considered features to
> many of us who worked on SBP-2. Details embedded below.
> David Wooten
> Frank Campbell <f_campbell at qlc.com> Wrote:
> | Before we consider withdrawal of SBP we should subject SBP-2 to greater
> | scrutiny.
> | There are aspects of SBP-2 which I believe should give rise to concern:
> | 1. SBP-2 requires that targets deal with scatter/gather and paging
> | issues within the host.
> Actually, I think the way that SBP-2 is described right now, the
> scatter/gather tables are a performance optimization. We could have described
> a transfer that had to be scattered/gathered with lots of individual commands.
> Each of these commands would have taken more bus cycles to fetch and more
> overhead on the device to process (in order to get reasonable performance, the
> target would have had to prefetch a large number of commands and discover the
> association through the target address.) So, after much debate, the group
> decided that these tables were less complex than the alternative(s).
Unfortunately, I was not present at these debates. Why would it have
been necessary to break up commands? IDE, SCSI and Fibrechannel do not
provide scatter/gather. Why is it necessary for 1394?
> | 2. SBP-2 requires that targets have the capability to break transfers
> | on odd byte boundaries.
> This is simply a property of the application. Many applications have the need
> to move data to arbitrary boundaries. Without this capability in SPB-2, the
> host would have to double-buffer which adds latency and decreases performance.
> Also, our BIOS experts told us that they simply did not have any reasonable
> amount of space laying around to support double buffering. So, we could have
> 'simplified' the device but that would have made it a bad fit to the
> Many disk drive people spent a lot of time wrestling with this. They had
> wanted sector alignment, but then conceded to quadlet alignment and then,
> after some more work, decided that byte alignment was merely an inconvenience
> and not a significant problem.
Again, since other interfaces do not provide this capability, why is it
necessary for SBP-2 to provide it? How do your BIOS experts deal with
odd byte boundaries and scatter/gather for IDE and SCSI?
> | 3. SBP-2 uses host addresses as handles with no means of identifying
> | stale handles, exposing the risk of stale handles causing corruption.
> I'm not sure what you mean here. SBP-2 uses actuall device addresses. When
> the node address gets stale due to a bus reset, the target stops its transfers
> and waits for the target to fixup the node addresses and reissue the commands.
My objection is that in the event that a stale handle is sent by a
target to a host, there is nothing in SBP-2 to identify it. Since the
handles are host addresses, a stale handle that involves a write can
cause corruption in host memory. If the assertion is that stale handles
will never occur and targets will always behave perfectly, then there is
> | 4. SBP-2 uses more bus transactions than necessary to perform I/O. As
> | worst case example, a single sector read from disk requires up to 14 bus
> | arbitration cycles and 14 packet transfers.
> I'm not sure where you get your 14 number from. Granted, one might conceive
> of a protocol that uses fewer bus transactions but I think it would be hard to
> out perform SBP-2 from a global context. I/O optimization is not simply a
> matter of using the fewest I/O bus transactions. Optimzation includes the
> time taken to get from endpoint to endpoint or to/from the application from/to
> the target. SPB-2 does a better job of this than anything we have seen from
> other buses.
What I quoted was a worst case example. 1394 is a split transaction bus
and hence, worst case, a read or write involves 2 bus arbitrations for 2
packets, request and response. For a single disk block read we have the
host writes to doorbell address to notify target
target reads the most recent ORB to get the address of the new ORB
target reads the new ORB
target reads page map
target writes data up to page boundary
target writes data from page boundary to end
target writes status
Seven reads or writes. Seven requests and seven responses. Fourteen
> | 5. SBP-2 hosts use DMA addresses supplied by targets, creating
> | problems.
> What security problem? The addresses are created by trusted software
> (drivers). So why do we have a security problem. What addresses could the
> device use that would not create a security problem?
The addresses may be created by 'trusted' software, but they are passed
to target devices which then are required to return them some time
later. I haven't seen anything in SBP-2 that would allow the 'trusting'
system to verify that they have not been changed/corrupted by the
> | Items 1,2 and 4 relate to the cost and complexity of target hardware and
> | firmware. Items 3 and 5 relate to reliability and security.
> | Frank Campbell
> | Qlogic Corporation
> | Costa Mesa, California.
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com
More information about the T10