From: Klaus Jensen <its@irrelevant.dk>
To: Jinhao Fan <fanjinhao21s@ict.ac.cn>
Cc: qemu-devel <qemu-devel@nongnu.org>,
Keith Busch <kbusch@kernel.org>,
Stefan Hajnoczi <stefanha@gmail.com>,
"open list:nvme" <qemu-block@nongnu.org>
Subject: Re: [PATCH v3 4/4] hw/nvme: add polling support
Date: Thu, 3 Nov 2022 13:10:53 +0100 [thread overview]
Message-ID: <Y2OvzcfeawKWvvJ0@cormorant.local> (raw)
In-Reply-To: <D1741E76-294E-41F6-B87B-70C2A4CF778C@ict.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 1280 bytes --]
On Nov 3 10:18, Jinhao Fan wrote:
> at 7:10 PM, Klaus Jensen <its@irrelevant.dk> wrote:
>
> > This doesn't do what you expect it to. By not updaring the eventidx it
> > will fall behind the actual head, causing the host to think that the
> > device is not processing events (but it is!), resulting in doorbell
> > ringing.
>
> I’m not sure I understand this correctly.
>
> In 7.13.1 in NVMe Spec 1.4c it says "If updating an entry in the Shadow
> Doorbell buffer **changes** the value from being less than or equal to the
> value of the corresponding EventIdx buffer entry to being greater than that
> value, then the host shall also update the controller's corresponding
> doorbell register to match the value of that entry in the Shadow Doorbell
> buffer.”
>
> So my understanding is that once the eventidx falls behind the actual head,
> the host will only ring the doorbell once but *not* for future submissions.
>
> Is this not what real hosts are doing?
I agree that the spec is a little unclear on this point. In any case, in
Linux, when the driver has decided that the sq tail must be updated,
it will use this check:
(new_idx - event_idx - 1) < (new_idx - old)
So it doesn't account for if or not eventidx was already behind.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2022-11-03 12:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-27 9:12 [PATCH v3 0/4] irqfd, iothread and polling support Jinhao Fan
2022-08-27 9:12 ` [PATCH v3 1/4] hw/nvme: support irq(de)assertion with eventfd Jinhao Fan
2022-08-27 9:12 ` [PATCH v3 2/4] hw/nvme: use KVM irqfd when available Jinhao Fan
2022-08-27 9:12 ` [PATCH v3 3/4] hw/nvme: add iothread support Jinhao Fan
2022-10-20 11:13 ` Klaus Jensen
2022-11-03 1:51 ` Jinhao Fan
2022-11-03 12:11 ` Klaus Jensen
2022-11-03 13:10 ` Jinhao Fan
2022-08-27 9:12 ` [PATCH v3 4/4] hw/nvme: add polling support Jinhao Fan
2022-10-20 11:10 ` Klaus Jensen
2022-11-03 2:18 ` Jinhao Fan
2022-11-03 12:10 ` Klaus Jensen [this message]
2022-11-03 13:19 ` Jinhao Fan
2022-11-04 6:32 ` Klaus Jensen
2022-11-08 12:39 ` John Levon
2022-11-08 14:11 ` Klaus Jensen
2022-11-09 4:35 ` Jinhao Fan
2022-10-20 11:16 ` [PATCH v3 0/4] irqfd, iothread and " Klaus Jensen
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=Y2OvzcfeawKWvvJ0@cormorant.local \
--to=its@irrelevant.dk \
--cc=fanjinhao21s@ict.ac.cn \
--cc=kbusch@kernel.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).