RE: Q Freezing Protocol Needed

[julian_satran@il.ibm.com]

ACA should take care of that.

However one caveat applies - ACA does not hold for task-queue full, busy
and reserved. We are
trying to talk those through ACA to see who will do what.

Julo

"Y P Cheng" <ycheng@advansys.com> on 20/12/2000 18:17:00

Please respond to "Y P Cheng" <ycheng@advansys.com>

To:   "Sudhanshu Mittal (TRIPACE/Zoetermeer)" <smittal@tripace.com>, "'IPS
      Reflector'" <ips@ece.cmu.edu>
cc:
Subject:  RE: Q Freezing Protocol Needed




> Hello All,
>    I have run into a problem on my iSCSI design. The problem concerns
> "Q Freezing" mechanism in Novell NetWare and UnixWare Operating Systems.
>
>    According to specifications of OS, in case of hardware error with
> any command (There is a list of errors), execution of further commands on
> that target should be stopped to facilitate error recovery
> mechanism of OS. In conventional HBA, it was no problem since
> commands are queued on HBA and it is the job of HBA to send next
> command to target; and in case of error, it will simply stop sending
> commands to that target till error condition has been cleared by OS.

The above statement might be true ten years ago but untrue today.  An HBA
today will send as many commands to a target device as the "target tag
queuing" allows.  The "tag ID" phase in SCSI selection allows an HBA to
send
more commands to one device.  Fibre channel devices do the same.  They are
known as multiple exchanges.  Commands and exchanges are not queued in an
HBA.

In fact, when multiple commands or exchanges arrive at a target, they could
be executed out of order.  In such case, the concept of Q-freeze does not
make sense.

> But in case of iSCSI, that technique cannot work since
> commands are queued on target and once command has left NIC, there is
> nothing it can do to stop the execution. ISCSI has made Auto
> Sense mandatory but that does not cover any error recovery
> mechanism that OS may wish to deploy.

I think you are talking about the inter-dependency of Q's or commands. The
only solution I know of is "don't give HBA the command if it depends on the
success of a previous command."  All software implementation knows this.

>    In addition, there is another specification - OS may ask HBA to
> freeze Q after execution of a command and HBA should not send any
> command to
> target from its queue till it receives clearance from OS. This is
probably
> more for diagnostic purposes (I have not seen any actual case so
> far) but it
> is part of OS specifications and needs to be complied with. Here
> again, I am
> not able to find any proper mechanism to achieve this. One way
> could be for
> NIC to examine whether any such request has been made by OS and
> stop sending
> commands but I do not like this method. Also, there are
> specifications like
> "Q Flush" and "Task Abort". In case of conventional HBA, these were no
> problems but here it becomes difficult to implement these.
>
>    Unless I am missing something very basic, no mechanism has been
> provided for these since these do not form part of T10/SAM-2
> specifications.
> But a mechanism is needed to achieve this so that an implementer
> can achieve
> OS specifications.
>
> Sincerely,
>
> Sudhanshu Mittal
>
> Tel #   +31 (79) 361 2444
> Visit our web site for more info:
> http://www.tripace.com/
>
> SCSI Chip Set(s), SCSI Host Adapters, SCSI Software Drivers to various
> Operating Systems
> SCSI, USB 2.0 & ATAPI/ATA Interconnectivity Chip Solutions
>
> C R E A T O R S   O F   D A T A   M O V I N G   W O R L D S
>

Y.P. Cheng, Connectcom Solutions.