From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Stefano Stabellini <stefano@aporeto.com>,
David Vrabel <dvrabel@cantab.net>
Cc: xen-devel@lists.xenproject.org, wei.liu2@citrix.com
Subject: Re: [DOC v1] Xen transport for 9pfs
Date: Fri, 2 Dec 2016 10:57:25 +0000 [thread overview]
Message-ID: <d7603712-6be7-06c3-fd14-f08f2b43fd86@citrix.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1612011548231.2781@sstabellini-ThinkPad-X260>
On 02/12/16 00:29, Stefano Stabellini wrote:
> On Wed, 30 Nov 2016, David Vrabel wrote:
>> On 29/11/16 23:34, Stefano Stabellini wrote:
>>> The producer (the backend for **in**, the frontend for **out**) writes to the
>>> array in the following way:
>>>
>> - read memory barrier
>>> - read *cons*, *prod* from shared memory
>>> - write to array at position *prod* up to *cons*, wrapping around the circular
>>> buffer when necessary
>> - write memory barrier
>>> - increase *prod*
>>> - notify the other end via evtchn
>>>
>>> The consumer (the backend for **out**, the frontend for **in**) reads from the
>>> array in the following way:
>> - read memory barrier
>>> - read *prod*, *cons* from shared memory
>>> - read from array at position *cons* up to *prod*, wrapping around the circular
>>> buffer when necessary
>>> - memory barrier
>>> - increase *cons*
>>> - notify the other end via evtchn
>> Your barriers are wrong (see corrections above).
> Thanks for the review. Sorry for not specifying the type of memory
> barriers. I agree with some of your suggestions, but I don't understand
> why you moved the read memory barrier before reading prod and cons.
>
> Shouldn't it be for a producer:
> - read *cons*, *prod* from shared memory
> - read memory barrier
> - write to array at position *prod* up to *cons*, wrapping around the circular
> buffer when necessary
> - write memory barrier
> - increase *prod*
> - notify the other end via evtchn
>
> and for a consumer:
> - read *prod*, *cons* from shared memory
> - read memory barrier
> - read from array at position *cons* up to *prod*, wrapping around the circular
> buffer when necessary
> - general memory barrier
> - increase *cons*
> - notify the other end via evtchn
>
> If this is wrong, could you please explain why?
It is wrong. A read barrier is used to separate two reads which must
happen in a certain order. A write barrier separates two writes. A
full memory barrier is required to separate a read from a write.
e.g.
foo = a;
smp_rmb();
bar = b;
and
a = foo';
smp_wmb();
b = bar';
Read and write barriers must come in matched pairs excluding the same
fields. If your pattern looks different to that, then you are using
them wrong.
If instead, you need to exclude reads from writes, then you must use
something looking like:
foo = a;
smp_mb();
b = bar;
on both sides.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-12-02 10:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-29 23:34 [DOC v1] Xen transport for 9pfs Stefano Stabellini
2016-11-30 10:59 ` David Vrabel
2016-12-02 0:29 ` Stefano Stabellini
2016-12-02 10:45 ` David Vrabel
2016-12-02 21:45 ` Stefano Stabellini
2016-12-02 10:57 ` Andrew Cooper [this message]
2016-12-01 10:56 ` Dario Faggioli
2016-12-01 23:14 ` Stefano Stabellini
2016-12-02 8:54 ` Dario Faggioli
2016-12-02 22:01 ` Stefano Stabellini
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=d7603712-6be7-06c3-fd14-f08f2b43fd86@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=dvrabel@cantab.net \
--cc=stefano@aporeto.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.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.