All of lore.kernel.org
 help / color / mirror / Atom feed
From: Klaus Jensen <its@irrelevant.dk>
To: Keith Busch <kbusch@kernel.org>
Cc: linux-nvme@lists.infradead.org, Jens Axboe <axboe@fb.com>,
	Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>
Subject: Re: shadow doorbell on admin queue
Date: Fri, 15 Jul 2022 09:07:30 +0200	[thread overview]
Message-ID: <YtESMhylPsbF08IB@apples> (raw)
In-Reply-To: <YtAjEzTmdrmaY9hw@kbusch-mbp.dhcp.thefacebook.com>

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

On Jul 14 08:07, Keith Busch wrote:
> On Thu, Jul 14, 2022 at 10:50:56AM +0200, Klaus Jensen wrote:
> > Hi,
> > 
> > Jinhao, our QEMU GSoC intern is working on nvme performance improvements
> > and while implementing shadow doorbells an interesting issue came up.
> > 
> > The spec states that when enabling shadow doorbells, it is for all
> > queues (including the admin queue). However, the kernel will currently
> > not update the shadow doorbell for the admin queue, which causes trouble
> > if the device expects it to.
> > 
> > The kernel is not the only driver doing this - SPDK doesn't update it
> > either[1]. At least one virtual target implementing shadow doorbells
> > (SPDK's vfio-user target) jumped on the band-wagon and simply expects
> > the driver to not update it. In QEMU, Keith came up with a hack to
> > update the shadow doorbell from the device side, allowing both compliant
> > and non-compliant drivers to work. Just fixing it on the driver side is
> > a problem, because it will break targets that expects the non-compliant
> > behavior (i.e. always expecting mmio on the admin queue).
> > 
> > Question is if the kernel even wants to do anything about this at all? I
> > kinda already know the answer here - "spec is screwed up", but I wanted
> > to raise the issue here for feedback prior to potentially starting a
> > process with the NVMe TWG to sort out there.
> 
> The driver has been this way forever, so either (a) no one was actually using
> this feature, or (b) every target implementing shadow doorbells has the same
> non-spec implementation. Either way, we can't very well change it now, and it
> looks like shadows can't reliably be used on a live queue anyway. I think you'd
> have to refine this feature with the TWG.

I agree - initializing the shadow values on the admin queue is a little
wonky. I'll bring this up with my reps in the TWG.

Thanks!

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

      reply	other threads:[~2022-07-15  7:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-14  8:50 shadow doorbell on admin queue Klaus Jensen
2022-07-14 14:07 ` Keith Busch
2022-07-15  7:07   ` Klaus Jensen [this message]

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=YtESMhylPsbF08IB@apples \
    --to=its@irrelevant.dk \
    --cc=axboe@fb.com \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /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.