Re: [PATCH 0/4] scsi: Support devices that don't have a cmd_per_lun limit

[Hannes Reinecke <hare@suse.de>]

On 4/23/26 18:40, Bart Van Assche wrote:
> On 4/23/26 2:45 AM, Hannes Reinecke wrote:
>> Ideally I would kill cmd_per_lun.
>> This really is a poor man's fairness algorithm (sole purpose is to
>> avoid starvation with many luns), and we really should look at if
>> we cannot replace it with tagsets.
> 
> Hmm ... isn't cmd_per_lun essential since the introduction of scsi-mq?
> Without a host-wide tagset, and with n hardware queues,
> blk_mq_alloc_tag_set() allocates (number of hardware queues) *
> (shost->can_queue + shost->nr_reserved_cmds) requests. Each request
> maps to one SCSI command. Setting cmd_per_lun to shost->can_queue may
> be essential to avoid BUSY responses from a SCSI device. Here is an
> example from the ib_srp driver (there are many more SCSI LLDs that
> follow this pattern):
> * During connection establishment, the SCSI target reports the
>    maximum queue depth it supports. This response is used to initialize
>    can_queue and cmd_per_lun.
> * Multiple hardware queues are allocated, all supporting can_queue
>    commands.
> * cmd_per_lun is set to can_queue to avoid BUSY responses from the SCSI
>    target. My experience is that for high performance SCSI targets even
>    1% BUSY responses cause a significant performance drop.
> 
My point being that cmd_per_lun is a single setting, and is extremely
imprecise. At the same time we already have fine-grained request QoS
available by virtue of tagsets.
Seems like we need to have a 'device_tagset' setting, too.
Hmm.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich