SCSI Queue algorithm modifier

Hello,

I'm wondering if anybody is familiar with the QUEUE ALGORITHM MODIFIER
field in the SCSI Control Mode Page (reading from SPC-3 7.4.6 page
285). Specifically, is this value set by the device server on the
target or the application client on the initiator? Is this a
negotiated value?

If this is something that the initiator has some say over, is
unrestricted reordering allowed by most initiators?

Some background: I'm with iSCSI devices here and am working on
implementing the SCSI layer of an iSCSI target library. I've checked
the setting between the IET target and the Microsoft iSCSI initiator
and it is set to 0. I'm wondering if it is worthwhile to put
reordering logic in my SCSI device code if no iSCSI initiators are
going to support it.

Thanks,
Wesley

Wesley Leggette wrote:
>
> Hello,
>
> I'm wondering if anybody is familiar with the QUEUE ALGORITHM MODIFIER
> field in the SCSI Control Mode Page (reading from SPC-3 7.4.6 page
> 285). Specifically, is this value set by the device server on the
> target or the application client on the initiator?

Both is possible.

> Is this a negotiated value?

It is not negotiated. For a normal MODE SENSE with PC=00b the device
server should report the current value. If multiple algorithms are
supported, the field should be marked as changeable (the MODE SENSE
command with PC=01b should report ones in this field).

It is allowed to support only one algorithm, in this case it is set by
the device server. If multiple algorithms are supported, the application
client can write a new value in this field.

> If this is something that the initiator has some say over,

Yes, an initiator can change it (if this is implemented in the target).

> is unrestricted reordering allowed by most initiators?
>
> Some background: I'm with iSCSI devices here and am working on
> implementing the SCSI layer of an iSCSI target library. I've checked
> the setting between the IET target and the Microsoft iSCSI initiator
> and it is set to 0. I'm wondering if it is worthwhile to put
> reordering logic in my SCSI device code if no iSCSI initiators are
> going to support it.

If your code is not running directly inside a disk controller (as I
would expect for an iSCSI target), your code IMHO don't have enough
information for this job. If you want to support unrestricted
reordering, you maybe implement it as passthrough: If reordering is
enabled by an initiator on the iSCSI target, enable it on the disk
controllers if they support it (and vice versa).

Note:
Be careful with multiple initiators. My SPC draft specify the "shared"
policy as allowed for the Control Mode page, but IMHO this is dangerous
here. Because an initiator must manage data integrity himself with
unrestricted reordering, your iSCSI target should handle the Control
Mode page with "per I_T nexus" policy if unrestricted reordering is
supported. Otherwise an initiator that cannot work with unrestricted
reordering simply get the UNIT ATTENTION condition that somebody else
have changed the Mode parameters (but it is very likely that he is not
able to switch that back to the required value himself).


Micha