All of lore.kernel.org
 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: [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 [PATCH] kni: fix kni rx fifo producer synchronization 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 ` [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 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.