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 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.