All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Mike Christie <michael.christie@oracle.com>
Cc: martin.petersen@oracle.com, linux-scsi@vger.kernel.org,
	james.bottomley@hansenpartnership.com,
	virtualization@lists.linux.dev, mst@redhat.com,
	pbonzini@redhat.com, eperezma@redhat.com
Subject: Re: [PATCH 4/4] virtio-scsi: Support scsi_devices without a device wide limit
Date: Mon, 20 Apr 2026 13:30:42 -0400	[thread overview]
Message-ID: <20260420173042.GA405461@fedora> (raw)
In-Reply-To: <20260417230751.117836-5-michael.christie@oracle.com>

[-- Attachment #1: Type: text/plain, Size: 1731 bytes --]

On Fri, Apr 17, 2026 at 05:57:24PM -0500, Mike Christie wrote:
> When exporting a NVMe drive or other high perf multiqueue enabled
> devices we may want to pass commands from the guest to the physical
> device without been throttled for artificial device wide limits. To
> allow the user to tell virtio-scsi that we don't have a LU wide
> command limit, this patch uses U32_MAX as a special cmd_per_lun value.
> 
> If U32_MAX is used for cmd_per_lun, virtio-scsi will set
> SCSI_UNLIMITED_CMD_PER_LUN for the scsi_device's queue limit. In this
> case there is no scsi_device wide queue limit and we only go by the
> the virtqueue limits (virtqueue limit is translated to scsi host
> can_queue which is translated to block layer per hardware queue limit).
> 
> There's a small chance of regression where an existing user could be
> using U32_MAX and we have been setting the cmd_per_lun to can_queue.
> However, I think in the cases the user was doing this, they will want
> the new behavior where they are only limited by can_queue because
> they have been trying to get the highest queue value possible.
> 
> Signed-off-by: Mike Christie <michael.christie@oracle.com>
> ---
>  drivers/scsi/virtio_scsi.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)

Hi Mike,
Please send a VIRTIO spec patch documenting the new meaning of U32_MAX
in the virtio-scsi's cmd_per_lun configuration field to
virtio-comment@lists.linux.dev. See
https://github.com/oasis-tcs/virtio-spec for details.

The Linux driver patches need to be be merged after the VIRTIO spec
change has been merged so that Linux stays spec-compliant and to avoid
collisions between in-progress VIRTIO changes.

Thanks,
Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2026-04-20 17:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-17 22:57 [PATCH 0/4] scsi: Support devices that don't have a cmd_per_lun limit Mike Christie
2026-04-17 22:57 ` [PATCH 1/4] scsi: Fix can_queue comments Mike Christie
2026-04-20  8:28   ` John Garry
2026-04-17 22:57 ` [PATCH 2/4] scsi: qedi: Fix command overqueueing Mike Christie
2026-04-20 16:45   ` Bart Van Assche
2026-04-20 17:47     ` Mike Christie
2026-04-20 18:02       ` Bart Van Assche
2026-04-20 18:48         ` Mike Christie
2026-04-17 22:57 ` [PATCH 3/4] scsi: Support scsi_devices without a device wide limit Mike Christie
2026-04-20 16:51   ` Bart Van Assche
2026-04-22 13:15   ` Hannes Reinecke
2026-04-22 18:06     ` Mike Christie
2026-04-23 10:02     ` John Garry
2026-04-23 10:32       ` Hannes Reinecke
2026-04-27  1:33         ` Martin K. Petersen
2026-04-17 22:57 ` [PATCH 4/4] virtio-scsi: " Mike Christie
2026-04-20 17:30   ` Stefan Hajnoczi [this message]
2026-04-20 17:37   ` Bart Van Assche
2026-04-20 17:33 ` [PATCH 0/4] scsi: Support devices that don't have a cmd_per_lun limit Stefan Hajnoczi
2026-04-22 18:05   ` Mike Christie
2026-04-23  9:45     ` Hannes Reinecke
2026-04-23 16:40       ` Bart Van Assche
2026-04-24  5:45         ` Hannes Reinecke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260420173042.GA405461@fedora \
    --to=stefanha@redhat.com \
    --cc=eperezma@redhat.com \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=michael.christie@oracle.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=virtualization@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.