On 20/05/2021 17:57, Bart Van Assche wrote:
not be limited to 16b?
Maybe I'm missing something but it is not clear to me why different
structures in the SCSI headers use different data types for can_queue
and cmd_per_lun?
For cmd_per_lun, is it related to SCSI task tag limit? SAM-3 says upto
64b for task tag, but then SAS uses 16b for TMF tag, so not sure.
Someone with more SCSI spec knowledge than we can clarify this.
$ git grep -nHEw '(cmd_per_lun|can_queue);' include/scsi
include/scsi/scsi_device.h:318: unsigned int can_queue;
include/scsi/scsi_host.h:372: int can_queue;
include/scsi/scsi_host.h:425: short cmd_per_lun;
include/scsi/scsi_host.h:612: int can_queue;
include/scsi/scsi_host.h:613: short cmd_per_lun;
It seems intentional that can_queue is int and cmd_per_lun is short.
Intentional? It is not clear to me why? Even high-performance drivers
like iSER and SRP set can_queue by default to a value that fits well in
a 16-bit variable (512 and 64 respectively). The highest value that I
found after a quick search is the following:
#define ISCSI_TOTAL_CMDS_MAX 4096
I guess int was used for can_queue as an arbitrarily big number.
And if we try to use 16b for can_queue, reducing size of
variables/structure members sometimes breaks things, from my experience.
Thanks,
John
