James Bottomley wrote: >> Should host->can_queue be set to (cmd_per_lun * max_lun) ? > > It depends on how the controller behaves. Setting can_queue and > cmd_per_lun tends to work for most SCSI controllers because the > actual scsi devices have queue depths << this number. If your > controller will behave like this (i.e. will not allow the internal > queue for a single lun to fill up to this depth) then you can keep > this setting (although, again, since this is probably fixed by the > firmware, you want to set cmd_per_lun to this value to avoid > excessive QUEUE_FULL returns). If the controller will happily load > all the available slots up for a single lun, then you might want > to think about reducing cmd_per_lun to some fraction of can_queue > (you could even set it to can_queue - 2 like the 3ware controller). The hptiop firmware works as the latter case. Should it be modified like this: host->can_queue = le32_to_cpu(iop_config.max_requests); - host->cmd_per_lun = le32_to_cpu(iop_config.max_requests); + host->cmd_per_lun = host->can_queue - 2; While the 3ware driver sets both can_queue and cmd_per_lun to 254: (3w-9xxx.h) #define TW_Q_LENGTH 256 #define TW_MAX_CMDS_PER_LUN 254 (3w-9xxx.c) .can_queue = TW_Q_LENGTH-2, .cmd_per_lun = TW_MAX_CMDS_PER_LUN Should can_queue be set to TW_Q_LENGTH ? HighPoint Linux Team - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
