[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 4/4] hw/nvme: add polling support
From: |
Klaus Jensen |
Subject: |
Re: [PATCH v3 4/4] hw/nvme: add polling support |
Date: |
Thu, 3 Nov 2022 13:10:53 +0100 |
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.
signature.asc
Description: PGP signature