From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: Kiran Kumar <kkokkilagadda@caviumnetworks.com>,
dev@dpdk.org, Konstantin Ananyev <konstantin.ananyev@intel.com>,
Bruce Richardson <bruce.richardson@intel.com>,
Santosh Shukla <santosh.shukla@caviumnetworks.com>
Subject: Re: [dpdk-dev] [PATCH] kni: fix kni rx fifo producer synchronization
Date: Thu, 16 Aug 2018 12:22:57 +0530 [thread overview]
Message-ID: <20180816065256.GA11266@jerin> (raw)
In-Reply-To: <5debc6df-9bed-597a-03e2-510372b849e0@intel.com>
-----Original Message-----
> Date: Thu, 9 Aug 2018 12:30:57 +0100
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> To: Kiran Kumar <kkokkilagadda@caviumnetworks.com>
> CC: dev@dpdk.org, Jerin Jacob <jerin.jacob@caviumnetworks.com>, Konstantin
> Ananyev <konstantin.ananyev@intel.com>, Bruce Richardson
> <bruce.richardson@intel.com>, Santosh Shukla
> <santosh.shukla@caviumnetworks.com>
> Subject: Re: [dpdk-dev] [PATCH] kni: fix kni rx fifo producer
> synchronization
> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
> Thunderbird/52.9.1
>
>
> On 8/9/2018 11:23 AM, Kiran Kumar wrote:
> > With existing code in kni_fifo_put, rx_q values are not being updated
> > before updating fifo_write. While reading rx_q in kni_net_rx_normal,
> > This is causing the sync issue on other core. So adding a write
> > barrier to make sure the values being synced before updating fifo_write.
> >
> > Fixes: 3fc5ca2f6352 ("kni: initial import")
> >
> > Signed-off-by: Kiran Kumar <kkokkilagadda@caviumnetworks.com>
> > ---
> > lib/librte_kni/rte_kni_fifo.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/lib/librte_kni/rte_kni_fifo.h b/lib/librte_kni/rte_kni_fifo.h
> > index ac26a8c..4d6b33e 100644
> > --- a/lib/librte_kni/rte_kni_fifo.h
> > +++ b/lib/librte_kni/rte_kni_fifo.h
> > @@ -39,6 +39,7 @@ kni_fifo_put(struct rte_kni_fifo *fifo, void **data, unsigned num)
> > fifo->buffer[fifo_write] = data[i];
> > fifo_write = new_write;
> > }
> > + rte_smp_wmb();
> > fifo->write = fifo_write;
> > return i;
>
> For Intel this is just a compiler barrier so no issue but not sure if a memory
> barrier is required here,
>
> Related code block is:
>
> |- for (i = 0; i < num; i++) {
> || new_write = (new_write + 1) & (fifo->len - 1);
> ||
> || if (new_write == fifo_read)
> || break;
> || fifo->buffer[fifo_write] = data[i];
> || fifo_write = new_write;
> || }
> | fifo->write = fifo_write;
>
> "fifo_write" is updated in the loop, so there is a dependency to it for
> "fifo->write". Can memory writes be reordered when there is a dependency?
>From CPU0 compiler instruction generation perspective, It will take care of the
dependency. In weakly ordered machine, it does NOT grandees CPU1 sees
fifo->write as final write.
So, IMO, This patch make sense. We are able to reproduce the problem on
arm64 machine with certain traffic.
>
> Cc'ed a few more people for comment.
next prev parent reply other threads:[~2018-08-16 7:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-09 10:23 Kiran Kumar
2018-08-09 11:30 ` Ferruh Yigit
2018-08-16 6:52 ` Jerin Jacob [this message]
2018-08-16 12:28 ` Ferruh Yigit
2018-08-16 9:01 ` Jerin Jacob
2018-08-16 9:55 ` [dpdk-dev] [PATCH v2] kni: fix kni Rx " Kiran Kumar
2018-08-27 14:07 ` Ferruh Yigit
2018-08-27 15:40 ` Gavin Hu
2018-08-28 10:43 ` Kokkilagadda, Kiran
2018-08-28 10:51 ` Kokkilagadda, Kiran
2018-08-28 19:30 ` Gavin Hu
2018-08-29 4:59 ` Honnappa Nagarahalli
2018-08-29 5:49 ` Kokkilagadda, Kiran
2018-08-29 7:34 ` Ola Liljedahl
2018-08-29 8:28 ` Jerin Jacob
2018-08-29 8:47 ` Ola Liljedahl
2018-08-29 8:57 ` Jerin Jacob
2018-09-13 17:40 ` Honnappa Nagarahalli
2018-09-13 17:51 ` Jerin Jacob
2018-09-13 23:45 ` Honnappa Nagarahalli
2018-09-14 2:45 ` Jerin Jacob
2018-09-18 15:53 ` Ferruh Yigit
2018-09-19 5:37 ` Honnappa Nagarahalli
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=20180816065256.GA11266@jerin \
--to=jerin.jacob@caviumnetworks.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=kkokkilagadda@caviumnetworks.com \
--cc=konstantin.ananyev@intel.com \
--cc=santosh.shukla@caviumnetworks.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).