DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.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 13:28:35 +0100	[thread overview]
Message-ID: <9341fc12-e844-164a-ba61-42eafa5e5e92@intel.com> (raw)
In-Reply-To: <20180816065256.GA11266@jerin>

On 8/16/2018 7:52 AM, Jerin Jacob wrote:
> -----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.

OK, thanks for clarification.

> 
>>
>> Cc'ed a few more people for comment.

  reply	other threads:[~2018-08-16 12:28 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
2018-08-16 12:28     ` Ferruh Yigit [this message]
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=9341fc12-e844-164a-ba61-42eafa5e5e92@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerin.jacob@caviumnetworks.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).