From: Jonas Pfefferle <pepperjo at japf.ch>
To: spdk@lists.01.org
Subject: Re: [SPDK] NVMe command ordering
Date: Fri, 23 Mar 2018 17:21:10 +0100 [thread overview]
Message-ID: <ximss-49448565@switchplus-mail.ch> (raw)
In-Reply-To: ximss-49410798@switchplus-mail.ch
[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]
One other thing I stumbled upon:
7.1 "There are no ordering restrictions for completions to the host."
Does that mean if, for example, command A and B were executed in order A,B
they do not have to complete in this order on the CQ?
Thanks,
Jonas
On Fri, 23 Mar 2018 12:59:54 +0100
"Jonas Pfefferle" <pepperjo(a)japf.ch> wrote:
> Thanks!
>
> On Fri, 23 Mar 2018 11:25:26 +0000
> Andrey Kuzmin <andrey.v.kuzmin(a)gmail.com> wrote:
>> On Fri, Mar 23, 2018, 12:04 Jonas Pfefferle <pepperjo(a)japf.ch>
>>wrote:
>>
>>> Hi @all,
>>>
>>> Can anyone clarify this for me:
>>> NVMe spec 6.3 Command Ordering Requirements
>>> "For all commands which are not part of a fused operation (refer to
>>>section
>>> 4.10), or for which the write size is greater than AWUN, each
>>>command is
>>> processed as an independent entity without reference to other
>>>commands
>>> submitted to the same I/O Submission Queue or to commands submitted
>>>to
>>> other
>>> I/O Submission Queues"
>>>
>>> So writes <= AWUN size are atomic but there is no ordering between
>>>the
>>> commands, e.g. write command A issued before write command B to the
>>>same
>>> LBA
>>> can be executed in order AB or BA, the only thing guaranteed is that
>>>they
>>> are executed atomically? And there is no way to enforce ordering
>>>except on
>>> the host side?
>>>
>>
>> Right, that's exactly what the spec says in that same paragraph you
>>quote
>> above: "If there are ordering requirements between these commands,
>>host
>> software or the associated application is required to enforce that
>>ordering
>> above the level of the controller. " (1.3a, P. 179).
>>
>> Regards,
>> Andrey
>>
>>
>>> Regards,
>>> Jonas
>>>
>>>
>>> _______________________________________________
>>> SPDK mailing list
>>> SPDK(a)lists.01.org
>>> https://lists.01.org/mailman/listinfo/spdk
>>>
>> --
>>
>> Regards,
>> Andrey
>
>
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk
next reply other threads:[~2018-03-23 16:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-23 16:21 Jonas Pfefferle [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-03-27 7:56 [SPDK] NVMe command ordering Jonas Pfefferle
2018-03-24 0:08 Paul Von-Stamwitz
2018-03-23 16:29 Marushak, Nathan
2018-03-23 16:23 Luse, Paul E
2018-03-23 11:59 Jonas Pfefferle
2018-03-23 11:25 Andrey Kuzmin
2018-03-23 9:04 Jonas Pfefferle
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=ximss-49448565@switchplus-mail.ch \
--to=spdk@lists.01.org \
/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