Re: [PATCH v4 04/29] scsi: core: Support allocating a pseudo SCSI device

[Hannes Reinecke <hare@suse.de>]

On 9/16/25 10:21, John Garry wrote:
> On 12/09/2025 19:21, Bart Van Assche wrote:
>> From: Hannes Reinecke <hare@suse.de>
>>
>> Allocate a pseudo SCSI device if 'nr_reserved_cmds' has been set. Pseudo
>> SCSI devices have the SCSI ID <max_id>:U64_MAX so they won't clash with
>> any devices the LLD might create. Pseudo SCSI devices are excluded from
>> scanning and will not show up in sysfs. Additionally, pseudo SCSI
>> devices are skipped by shost_for_each_device(). This prevents that the
>> SCSI error handler tries to submit a reset to a non-existent logical 
>> unit.
>>
>> Do not allocate a budget map for pseudo SCSI devices since the
>> cmd_per_lun limit does not apply to pseudo SCSI devices.
> 
> IDGI, in v3 series you said that you would allocate the budget map 
> https://lore.kernel.org/linux-scsi/20250827000816.2370150-1- 
> bvanassche@acm.org/T/#m13c361e081b886b9318238b6dc05b571840b9698
> 
> FWIW, I still think that it is worth allocating the budget map for the 
> psuedo sdev and making the queue depth the same as nr_reserved_commands 
> via a scsi_change_queue_depth() call.
> 
No. budget map is only for resource arbitration between several devices
sharing the same underlying bitmap. Which doesn't apply for the pseudo
device; that is a virtual device pointing to the HBA itself, of which
we only every will have _one_.

> If we want to optimise budget code handling, then I think that it is 
> worth doing later. The whole budget map and cmd_per_lun handling is 
> murky IMHO.
> 
Oh, most definitely. budget map / cmd_per_lun was okay for single queue
devices where we couldn't really tell how many commands we should send.
But for multiqueue we know exactly how many commands should be possible,
so for _real_ multiqueue devices cmd_per_lun is pretty pointless if not
downright detrimental.
_Unless_ we have a multiqueue device with a shared host tagset, then it
sort of would make sense. But then one wonders why sbitmap doesn't do
that internally.

Sounds like a fun topic for ALPSS.

>>
>> Do not perform queue depth ramp up / ramp down for pseudo SCSI devices.
> 
> Are we even ever going to try ramp up or down for the pseudo sdev?
> 
No. Why would you want to restrict the number of eg TMFs you could send?

> I suppose we could see it if there is some internal reserved command 
> error, right?
> 
That would be equivalent to the HBA rejecting TMFs with 'out of 
resources'. At which point I would declare the HBA hosed and do
a full host/PCI reset.

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