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 0/4] scsi: Support devices that don't have a cmd_per_lun limit
Date: Mon, 20 Apr 2026 13:33:52 -0400	[thread overview]
Message-ID: <20260420173352.GB405461@fedora> (raw)
In-Reply-To: <20260417230751.117836-1-michael.christie@oracle.com>

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

On Fri, Apr 17, 2026 at 05:57:20PM -0500, Mike Christie wrote:
> 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.

Hi Mike,
Is there a difference between setting cmd_per_lun to U32_MAX with your
patches versus setting cmd_per_lun to the virtqueue size without your
patches (this can already be done today without code changes in the
driver)?

Thanks,
Stefan

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

  parent reply	other threads:[~2026-04-20 17:33 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
2026-04-20 17:37   ` Bart Van Assche
2026-04-20 17:33 ` Stefan Hajnoczi [this message]
2026-04-22 18:05   ` [PATCH 0/4] scsi: Support devices that don't have a cmd_per_lun limit 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=20260420173352.GB405461@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.