residue of 1394 Sbp-2 - forget it?

Byan, Stephen Stephen_Byan at maxtor.com
Thu Mar 7 08:04:19 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Byan, Stephen" <Stephen_Byan at Maxtor.com>
*
Pat LaVarre [mailto:LAVARRE at iomega.com] wrote:
 
> Seems to me, with Sbp-2, the bridge is stuck translating the 
> command set.  The
> bridge has to form a redundant opinion of how many bytes 
> should move which
> way, just so that it can check that is indeed what happens, 
> just so that it
> can report inappropriately nonzero residue as an error.

In general, I think bridging between different SCSI transports is almost
always inherently stateful, meaning that the bridge needs to do just what
you describe: interpret the command-set. 

Beside the issue you point out, SCSI also requires the logical unit to be
aware of how many initiators to which it is talking, and to maintain state
(such as allegiance state) for each intiator. There may be some combinations
of transports where this can be bridged statelessly, but in general I think
the bridge is stuck having to interpret commands.

Another reason for interpreting commands in a bridge might be to accomodate
the differences in flow-control between the transports. If you're bridging
fibre channel to a parallel scsi device, and the bridge runs out of BB
credits, it can't simply ask the parallel SCSI device to switch to commands
for an initiator for which the brdige has available credit. It's stuck, as
the SCSI target decides when to get off the bus. In this case, the bridge
wish to perform extensive internal buffering; for the bridge to accept data
in advance of the initiator it must be able to interpret the command in
order to proxy for the initiator.

In the restricted case where the bridged target supports a larger initiator
address space than the bridged-to transport, and the bridge punts on
flow-control issues, the bridge might be able to get away with only
maintaining the state of an initiator address translation table, and
maserading as the appropriate intitiator when talking to the device.

Regards,
-Steve

Steve Byan
<stephen_byan at maxtor.com>
Design Engineer
Maxtor Corp.
MS 1-3/E23
333 South Street
Shrewsbury, MA 01545
(508)770-3414
fax: (508)770-2604 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list