DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Kuusisaari, Juhamatti" <Juhamatti.Kuusisaari@coriant.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct	location
Date: Mon, 11 Jul 2016 11:22:43 +0000	[thread overview]
Message-ID: <HE1PR04MB1337E26DB33E9E9F8196FF0B9D3F0@HE1PR04MB1337.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB97725836B7C858@irsmsx105.ger.corp.intel.com>


Hi,
 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Juhamatti
> > Kuusisaari
> > Sent: Monday, July 11, 2016 11:21 AM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct
> > location
> >
> > Fix the location of the rte_ring data dependency read barrier.
> > It needs to be called before accessing indexed data to ensure that the
> > data itself is guaranteed to be correctly updated.
> >
> > See more details at kernel/Documentation/memory-barriers.txt
> > section 'Data dependency barriers'.
> 
> 
> Any explanation why?
> From my point smp_rmb()s are on the proper places here :) Konstantin

The problem here is that on a weak memory model system the CPU is
allowed to load the address data out-of-order in advance.
If the read barrier is after the DEQUEUE, you might end up having the old 
data there on a race situation when the buffer is continuously full.
Having it before the DEQUEUE guarantees that the load is not done
in advance. 

On Intel, it should not matter due to different memory model, so this is 
limited to weak memory model systems.

--
 Juhamatti
 
> >
> > Signed-off-by: Juhamatti Kuusisaari <juhamatti.kuusisaari@coriant.com>
> > ---
> >  lib/librte_ring/rte_ring.h | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
> > index eb45e41..a923e49 100644
> > --- a/lib/librte_ring/rte_ring.h
> > +++ b/lib/librte_ring/rte_ring.h
> > @@ -662,9 +662,10 @@ __rte_ring_mc_do_dequeue(struct rte_ring *r,
> void **obj_table,
> >                                               cons_next);
> >         } while (unlikely(success == 0));
> >
> > +       rte_smp_rmb();
> > +
> >         /* copy in table */
> >         DEQUEUE_PTRS();
> > -       rte_smp_rmb();
> >
> >         /*
> >          * If there are other dequeues in progress that preceded us,
> > @@ -746,9 +747,10 @@ __rte_ring_sc_do_dequeue(struct rte_ring *r,
> void **obj_table,
> >         cons_next = cons_head + n;
> >         r->cons.head = cons_next;
> >
> > +       rte_smp_rmb();
> > +
> >         /* copy in table */
> >         DEQUEUE_PTRS();
> > -       rte_smp_rmb();
> >
> >         __RING_STAT_ADD(r, deq_success, n);
> >         r->cons.tail = cons_next;
> > --
> > 2.9.0
> >
> >
> >
> ==========================================================
> ==
> > The information contained in this message may be privileged and
> > confidential and protected from disclosure. If the reader of this
> > message is not the intended recipient, or an employee or agent
> > responsible for delivering this message to the intended recipient, you
> > are hereby notified that any reproduction, dissemination or
> > distribution of this communication is strictly prohibited. If you have
> > received this communication in error, please notify us immediately by
> > replying to the message and deleting it from your computer. Thank you.
> > Coriant-Tellabs
> >
> ==========================================================
> ==

  reply	other threads:[~2016-07-11 11:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-11 10:20 Juhamatti Kuusisaari
2016-07-11 10:41 ` Ananyev, Konstantin
2016-07-11 11:22   ` Kuusisaari, Juhamatti [this message]
2016-07-11 11:40     ` Olivier Matz
2016-07-12  4:10       ` Kuusisaari, Juhamatti
2016-07-11 12:34     ` Ananyev, Konstantin
2016-07-12  5:27       ` Kuusisaari, Juhamatti
2016-07-12 11:01         ` Ananyev, Konstantin
2016-07-12 17:58           ` Ananyev, Konstantin
2016-07-13  5:27             ` Kuusisaari, Juhamatti
2016-07-13 13:00               ` Ananyev, Konstantin
2016-07-14  4:17                 ` Kuusisaari, Juhamatti
2016-07-14 12:56                   ` Ananyev, Konstantin
2016-07-15  5:40                     ` Kuusisaari, Juhamatti
2016-07-15  6:29                     ` Jerin Jacob
2016-07-15 10:34                       ` Ananyev, Konstantin
2016-07-18  2:47                         ` Jerin Jacob

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=HE1PR04MB1337E26DB33E9E9F8196FF0B9D3F0@HE1PR04MB1337.eurprd04.prod.outlook.com \
    --to=juhamatti.kuusisaari@coriant.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.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).