Re: [PATCH RFC v2 02/24] scsi: allocate separate queue for reserved commands

From: John Garry
Date: Wed Mar 11 2020 - 03:51:25 EST


On 11/03/2020 06:58, Hannes Reinecke wrote:
On 3/11/20 7:22 AM, Christoph Hellwig wrote:
On Tue, Mar 10, 2020 at 09:08:56PM +0000, John Garry wrote:
On 10/03/2020 18:32, Christoph Hellwig wrote:
On Wed, Mar 11, 2020 at 12:25:28AM +0800, John Garry wrote:
From: Hannes Reinecke <hare@xxxxxxxx>

Allocate a separate 'reserved_cmd_q' for sending reserved commands.

Why? Reserved command specifically are not in any way tied to queues.
.


So the v1 series used a combination of the sdev queue and the per-host
reserved_cmd_q. Back then you questioned using the sdev queue for virtio
scsi, and the unconfirmed conclusion was to use a common per-host q. This is
the best link I can find now:

https://www.mail-archive.com/linux-scsi@xxxxxxxxxxxxxxx/msg83177.html

That was just a question on why virtio uses the per-device tags, which
didn't look like it made any sense. What I'm worried about here is
mixing up the concept of reserved tags in the tagset, and queues to use
them. Note that we already have the scsi_get_host_dev to allocate
a scsi_device and thus a request_queue for the host itself. That seems
like the better interface to use a tag for a host wide command vs
introducing a parallel path.

Ah. Right.
Will be looking into that, and convert the patchset over to it.


Hannes,

I assume that you will take back over this series now. Let me know. The patches are here, if not in patchwork:
https://github.com/hisilicon/kernel-dev/tree/private-topic-sas-5.6-resv-commands-v2

And the problem of the separate queue is the fact that I'll need a queue
to reserve tags from; trying to allocate a tag directly from the bitmap
turns out to be major surgery in the blocklayer with no immediate gain.
And I can't use per-device queues as for some drivers the reserved
commands are used to query the HBA itself to figure out how many devices
are present.

Right, we still need to be able to allocate somewhere apart from sdev queue




Thanks