Re: Q Freezing Protocol Needed

[Stephen Bailey <steph@cs.uchicago.edu>]

> 	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