From: Mike Christie <michael.christie@oracle.com>
To: martin.petersen@oracle.com, linux-scsi@vger.kernel.org,
james.bottomley@hansenpartnership.com,
virtualization@lists.linux.dev, mst@redhat.com,
pbonzini@redhat.com, stefanha@redhat.com, eperezma@redhat.com
Subject: [PATCH 0/4] scsi: Support devices that don't have a cmd_per_lun limit
Date: Fri, 17 Apr 2026 17:57:20 -0500 [thread overview]
Message-ID: <20260417230751.117836-1-michael.christie@oracle.com> (raw)
The following patches were made over Linus's and Martin's 7.1 trees.
They fix an issue where for virtio-scsi we export a lot of non-scsi
devices but are getting throttled by the cmd_per_lun_limit too early.
For example we export 1 or more NVMe or block devices and would like
to just pass command to them in way where virtio-scsi's hw queue
limits match the physical hardware. Or in some cases we are doing
cgroup based throttling on the host side, and we don't want the guest
to block IO when the host knows we have extra bandwidth.
The patches add a new cmd_per_lun value so drivers can indicate
when to avoid tracking queueing at the device wide level. They
then rely on just the block layer hw queue limits. And the patches
convert virtio-scsi. They also fix some can_queue related issues
discovered while testing/reviewing.
next reply other threads:[~2026-04-17 23:08 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-17 22:57 Mike Christie [this message]
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
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=20260417230751.117836-1-michael.christie@oracle.com \
--to=michael.christie@oracle.com \
--cc=eperezma@redhat.com \
--cc=james.bottomley@hansenpartnership.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=stefanha@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox