Re: [PATCH] hptiop: HighPoint RocketRAID 3xxx controller driver

[HighPoint Linux Team]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/