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

[John Garry <john.g.garry@oracle.com>]

On 16/09/2025 09:44, Hannes Reinecke wrote:
> 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://urldefense.com/v3/__https://lore.kernel.org/linux- 
>> scsi/20250827000816.2370150-1-__;!!ACWV5N9M2RV99hQ! 
>> PXP56tO8nGuApLOmFXRDRrX5- 
>> UTPdJrsBgtullL3kVHsDxEZ0GtNqiKsGG1CxDiJjcvLSCcwCkBkO9U$ 
>> 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_.

What you write is true. However, I am just suggesting a method to keep 
the core code clean, even if we are not sticking to the tenet of queue 
depths only applying to real sdevs.

> 
>> 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?

My question was really theory vs practice, that being - are we going to 
see "queue full" errors for reserved commands which will lead us to 
entering the queue depth ramping? The answer is below...

> 
>> 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.

Sure, maybe that is the best way to go.

Thanks,
John