RE: Q Freezing Protocol Needed

[Charles Monia <cmonia@NishanSystems.com>]

Hi:

I was unclear as to the O/S expectation in such cases.  My guess was that
the assumptions are based on SCSI-2 semantics and the parallel SCSI
transport. Specificatlly:

a)  No commands in flight -- commands are either pending in the target or
queued in the host waiting to be sent.  For adapter-resident queues, some
parallel SCSI adapters  would check status and automatically freeze the
queue when a CHECK CONDITION status was returned.

b)  No target support for autosense.  In this case, the host must intervene
to capture sense data before command processing can continue.

Charles

> -----Original Message-----
> From: Stephen Bailey [mailto:steph@cs.uchicago.edu]
> Sent: Wednesday, December 20, 2000 12:01 PM
> To: ips@ece.cmu.edu
> Subject: Re: Q Freezing Protocol Needed 
> 
> 
> > 	I have run into a problem on my iSCSI design. The 
> problem concerns
> > "Q Freezing" mechanism in Novell NetWare and UnixWare 
> Operating Systems.
> 
> Implementing CAM semantics, eh?  That to those of you who said CAM was
> moribund (lesse, that's Tru64, FreeBSD, AND Netware, well, now that I
> think about it I was the one that said it :^).
> 
> The existing mechanisms within iSCSI (and SAM) are as adequate for
> implementing this behavior as any other SCSI protocol (FCP, ||SCSI,
> SPI :^).
> 
> The key is where you draw your architectural dotted lines.  In the
> typical situation, the SIM queues (the per LUN queues that get
> frozen), are implemented in the driver.  Any commands which are given
> to the adapter are considered to be `on the wire' whether they are or
> not.
> 
> In the case where a SIM queue is frozen when multiple queued commands
> are outstanding, it is not required that no further commands are
> executed by the LUN.  What is required is that once all the commands
> outstanding to the LUN (either already delivered to the target, or
> queued somewhere in the delivery subsystem, of which the NIC is a
> part) complete, no NEW commands will be started until the queue is
> thawed.  You can perform the single stepping by sending a
> head-of-queue, unqueued, freeze-the-SIM-queue, command after you
> detect a queue freeze, then unfreeze the queue.  The unqueued command
> must wait for all the queued commands to complete (your driver does
> this!), then it will be executed and its completion will refreeze the
> queue.  At that point, you can keep executing single stepped commands,
> or thaw the queue and let everybody run.  All of this queue management
> is implemented by your driver as part of its contract with the SCSI
> upper layers.
> 
> If Netware has a reference SCSI port driver (Tru64 certainly doesn't),
> it should illustrate this.  The SIM queue is pretty much never in the
> adapter, except in certain obscure adapters made by Compaq and
> GENROCO.
> 
> Steph
>