>
> On Fri, 30 Nov 2018 21:56:30 +0100
> Mattias Rönnblom wrote:
>
> > On 2018-11-30 03:13, Honnappa Nagarahalli wrote:
> > >>
> > >> Reinventing RCU is not helping anyone.
> > > IMO, this depends on what the rte_tqs has to offer and what the
> requirements are. Before starting this patch, I loo
On Fri, 30 Nov 2018 21:56:30 +0100
Mattias Rönnblom wrote:
> On 2018-11-30 03:13, Honnappa Nagarahalli wrote:
> >>
> >> Reinventing RCU is not helping anyone.
> > IMO, this depends on what the rte_tqs has to offer and what the
> > requirements are. Before starting this patch, I looked at the l
On 2018-11-30 03:25, Honnappa Nagarahalli wrote:
Generally I'm in favour of using established libraries (particularly for complex
functionality like RCU) but in this case I think there's a tradeoff with raw
performance.
The licensing info [1] is very interesting. Again I am no lawyer :)
[1]
ht
On 2018-11-30 03:13, Honnappa Nagarahalli wrote:
Reinventing RCU is not helping anyone.
IMO, this depends on what the rte_tqs has to offer and what the requirements
are. Before starting this patch, I looked at the liburcu APIs. I have to say,
fairly quickly (no offense) I concluded that this
Hi Luca,
Appreciate your comments.
>
> liburcu has many flavours already, qsbr being one of them. If none of those
> are optimal for this use case, why not work with upstream to either improve
> the existing flavours, or add a new one?
>
> You have the specific knowledge and expertise ab
On Fri, 30 Nov 2018 16:26:25 +
Luca Boccassi wrote:
> On Fri, 2018-11-30 at 02:13 +, Honnappa Nagarahalli wrote:
> > >
> > > > > > Mixed feelings about this one.
> > > > > >
> > > > > > Love to see RCU used for more things since it is much better
> > > > > > than
> > > > > > reader/wr
On Fri, 2018-11-30 at 02:13 +, Honnappa Nagarahalli wrote:
> >
> > > > > Mixed feelings about this one.
> > > > >
> > > > > Love to see RCU used for more things since it is much better
> > > > > than
> > > > > reader/writer locks for many applications. But hate to see
> > > > > DPDK
> > > > >
> > >
> >
> > Mixed feelings about this one.
> >
> > Love to see RCU used for more things since it is much better than
> > reader/writer locks for many applications. But hate to see DPDK
> > reinventing every other library and not reusing code. Userspace RCU
> > https://liburcu.org/ is widely suppo
>
> > > > Mixed feelings about this one.
> > > >
> > > > Love to see RCU used for more things since it is much better than
> > > > reader/writer locks for many applications. But hate to see DPDK
> > > > reinventing every other library and not reusing code. Userspace
> > > > RCU https://liburcu.org
On Wed, 28 Nov 2018 05:31:56 +
Honnappa Nagarahalli wrote:
> > > Mixed feelings about this one.
> > >
> > > Love to see RCU used for more things since it is much better than
> > > reader/writer locks for many applications. But hate to see DPDK
> > > reinventing every other library and not reu
> >
> > On Wed, 21 Nov 2018 21:30:52 -0600
> > Honnappa Nagarahalli wrote:
> >
> > > Lock-less data structures provide scalability and determinism.
> > > They enable use cases where locking may not be allowed (for ex:
> > > real-time applications).
> > >
>
>
>
> > > Dharmik Thakkar (1):
> > >
> Subject: Re: [dpdk-dev] [RFC 0/3] tqs: add thread quiescent state library
>
> On Wed, 21 Nov 2018 21:30:52 -0600
> Honnappa Nagarahalli wrote:
>
> > Lock-less data structures provide scalability and determinism.
> > They enable use cases where locking may no
On Wed, 21 Nov 2018 21:30:52 -0600
Honnappa Nagarahalli wrote:
> Lock-less data structures provide scalability and determinism.
> They enable use cases where locking may not be allowed
> (for ex: real-time applications).
>
> In the following paras, the term 'memory' refers to memory allocated
>
Hi.
Is the any differentiation points with liburcu [1] ?
Is there any profit having own implementation inside DPDK ?
[1] http://liburcu.org/
https://lwn.net/Articles/573424/
Best regards, Ilya Maximets.
> Lock-less data structures provide scalability and determinism.
> They enable use cases
14 matches
Mail list logo