On Tue, Mar 29, 2016 at 7:04 PM, Bruce Richardson
wrote:
>
> On Tue, Mar 29, 2016 at 05:29:12PM +0200, Olivier MATZ wrote:
> > Hi,
> >
> >
> > On 03/29/2016 10:54 AM, Bruce Richardson wrote:
> > >On Mon, Mar 28, 2016 at 06:48:07PM +0300, Lazaros Koromilas wrote:
> > >>Hi Olivier,
> > >>
> > >>We c
Hi,
On 03/29/2016 10:54 AM, Bruce Richardson wrote:
> On Mon, Mar 28, 2016 at 06:48:07PM +0300, Lazaros Koromilas wrote:
>> Hi Olivier,
>>
>> We could have two threads (running on different cores in the general
>> case) that both succeed the cmpset operation. In the dequeue path,
>> when n == 0,
On Tue, Mar 29, 2016 at 05:29:12PM +0200, Olivier MATZ wrote:
> Hi,
>
>
> On 03/29/2016 10:54 AM, Bruce Richardson wrote:
> >On Mon, Mar 28, 2016 at 06:48:07PM +0300, Lazaros Koromilas wrote:
> >>Hi Olivier,
> >>
> >>We could have two threads (running on different cores in the general
> >>case) t
On Mon, Mar 28, 2016 at 06:48:07PM +0300, Lazaros Koromilas wrote:
> Hi Olivier,
>
> We could have two threads (running on different cores in the general
> case) that both succeed the cmpset operation. In the dequeue path,
> when n == 0, then cons_next == cons_head, and cmpset will always
> succee
Hi Olivier,
We could have two threads (running on different cores in the general
case) that both succeed the cmpset operation. In the dequeue path,
when n == 0, then cons_next == cons_head, and cmpset will always
succeed. Now, if they both see an old r->cons.tail value from a
previous dequeue, the
Hi Lazaros,
On 03/17/2016 04:49 PM, Lazaros Koromilas wrote:
> Issuing a zero objects dequeue with a single consumer has no effect.
> Doing so with multiple consumers, can get more than one thread to succeed
> the compare-and-set operation and observe starvation or even deadlock in
> the while loo
> > Issuing a zero objects dequeue with a single consumer has no effect.
> > Doing so with multiple consumers, can get more than one thread to succeed
> > the compare-and-set operation and observe starvation or even deadlock in
> > the while loop that checks for preceding dequeues. The problematic
On 3/22/2016 6:13 PM, Richardson, Bruce wrote:
> On Mon, Mar 21, 2016 at 05:47:44PM +, Xie, Huawei wrote:
>> On 3/18/2016 10:17 PM, Bruce Richardson wrote:
>>> On Fri, Mar 18, 2016 at 01:47:29PM +0100, Mauricio V?squez wrote:
Hi,
On Fri, Mar 18, 2016 at 11:35 AM, Thomas Monj
On Mon, Mar 21, 2016 at 05:47:44PM +, Xie, Huawei wrote:
> On 3/18/2016 10:17 PM, Bruce Richardson wrote:
> > On Fri, Mar 18, 2016 at 01:47:29PM +0100, Mauricio V?squez wrote:
> >> Hi,
> >>
> >>
> >> On Fri, Mar 18, 2016 at 11:35 AM, Thomas Monjalon >> 6wind.com
> >>> wrote:
> >>> 2016-03-18 1
On 3/18/2016 10:17 PM, Bruce Richardson wrote:
> On Fri, Mar 18, 2016 at 01:47:29PM +0100, Mauricio V?squez wrote:
>> Hi,
>>
>>
>> On Fri, Mar 18, 2016 at 11:35 AM, Thomas Monjalon > 6wind.com
>>> wrote:
>>> 2016-03-18 11:27, Olivier Matz:
On 03/18/2016 11:18 AM, Bruce Richardson wrote:
>>
Hi,
On 03/17/2016 04:49 PM, Lazaros Koromilas wrote:
> Issuing a zero objects dequeue with a single consumer has no effect.
> Doing so with multiple consumers, can get more than one thread to succeed
> the compare-and-set operation and observe starvation or even deadlock in
> the while loop that c
On Fri, Mar 18, 2016 at 01:47:29PM +0100, Mauricio V?squez wrote:
> Hi,
>
>
> On Fri, Mar 18, 2016 at 11:35 AM, Thomas Monjalon 6wind.com
> > wrote:
>
> > 2016-03-18 11:27, Olivier Matz:
> > > On 03/18/2016 11:18 AM, Bruce Richardson wrote:
> > > >>> + /* Avoid the unnecessary cmpset oper
Hi,
On Fri, Mar 18, 2016 at 11:35 AM, Thomas Monjalon wrote:
> 2016-03-18 11:27, Olivier Matz:
> > On 03/18/2016 11:18 AM, Bruce Richardson wrote:
> > >>> + /* Avoid the unnecessary cmpset operation below, which is
> also
> > >>> +* potentially harmful when n equals 0. */
> > >>>
2016-03-18 11:27, Olivier Matz:
> On 03/18/2016 11:18 AM, Bruce Richardson wrote:
> >>> + /* Avoid the unnecessary cmpset operation below, which is also
> >>> +* potentially harmful when n equals 0. */
> >>> + if (n == 0)
> >>>
> >>
> >> What about using unlikely here?
> >>
> >
Hi,
On 03/18/2016 11:18 AM, Bruce Richardson wrote:
>>> diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
>>> index 943c97c..eb45e41 100644
>>> --- a/lib/librte_ring/rte_ring.h
>>> +++ b/lib/librte_ring/rte_ring.h
>>> @@ -431,6 +431,11 @@ __rte_ring_mp_do_enqueue(struct rte_ring
On Fri, Mar 18, 2016 at 11:27:18AM +0100, Olivier Matz wrote:
> Hi,
>
> On 03/18/2016 11:18 AM, Bruce Richardson wrote:
> >>> diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
> >>> index 943c97c..eb45e41 100644
> >>> --- a/lib/librte_ring/rte_ring.h
> >>> +++ b/lib/librte_ring/
On Thu, Mar 17, 2016 at 05:09:08PM +0100, Mauricio V?squez wrote:
> Hi Lazaros,
>
> On Thu, Mar 17, 2016 at 4:49 PM, Lazaros Koromilas
> wrote:
>
> > Issuing a zero objects dequeue with a single consumer has no effect.
> > Doing so with multiple consumers, can get more than one thread to succeed
Issuing a zero objects dequeue with a single consumer has no effect.
Doing so with multiple consumers, can get more than one thread to succeed
the compare-and-set operation and observe starvation or even deadlock in
the while loop that checks for preceding dequeues. The problematic piece
of code w
Hi Lazaros,
On Thu, Mar 17, 2016 at 4:49 PM, Lazaros Koromilas
wrote:
> Issuing a zero objects dequeue with a single consumer has no effect.
> Doing so with multiple consumers, can get more than one thread to succeed
> the compare-and-set operation and observe starvation or even deadlock in
> th
19 matches
Mail list logo
