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 <[email protected]> > --- > 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 [email protected]. 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
signature.asc
Description: PGP signature
