...@arm.com>; lng-odp@lists.linaro.org
Subject: Re: [lng-odp] 32-bit support in examples
On 23 January 2017 at 09:50, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolai...@nokia-bell-labs.com> wrote:
> -Original Message-
> From: Brian Brooks [mailto:brian.bro...@linaro.org]
&
t; From: Joe Savage [mailto:joe.sav...@arm.com]
>> > Sent: Friday, January 20, 2017 1:51 PM
>> > To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
>> > labs.com>; Maxim Uvarov <maxim.uva...@linaro.org>; lng-
>> > o...@lists.linaro.
ncois Ozog <francois.o...@linaro.org>
> > Cc: Bill Fischofer <bill.fischo...@linaro.org>; Joe Savage
> > <joe.sav...@arm.com>; Maxim Uvarov <maxim.uva...@linaro.org>;
> Savolainen,
> > Petri (Nokia - FI/Espoo) <petri.savolai...@nokia-bell-labs.com&g
On 20 January 2017 at 14:36, Francois Ozog wrote:
> well, yes. But that is the only atomic operation supported. No add, sub,
> inc, xadd, bit operations
>
Using lock cmpxchg16b (i.e. atomic CAS), GCC implements all of the __atomic
operations on 128-bit operands.
Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
> > labs.com>; Maxim Uvarov <maxim.uva...@linaro.org>; lng-
> > o...@lists.linaro.org; Bill Fischofer <bill.fischo...@linaro.org>
> > Cc: nd <n...@arm.com>
> > Subject: Re: [lng-odp] 32-bit suppo
The kernel has used a set of spinlocks to help dealing with atomics in
certain conditions (architecture, length of bitfield...).
A discussion on what atomi operations are needed may be of value to ODP too:
https://lwn.net/Articles/695257/
On 23 January 2017 at 10:49, Joe Savage
> Any atomics can be emulated in SW (using compiler built-ins or locks
> directly). The point here is the missing HW support:
> * E.g. MIPS, Power, ARMv7 do not have 128 bit CAS
> * 128 bit fetch-and-add is not supported in any of the architectures
>
> We need to ensure on any operations added
axim Uvarov <maxim.uva...@linaro.org>; Savolainen,
> Petri (Nokia - FI/Espoo) <petri.savolai...@nokia-bell-labs.com>; lng-
> o...@lists.linaro.org; nd <n...@arm.com>
> Subject: Re: [lng-odp] 32-bit support in examples
>
> CAS is a universal primitive in the se
CAS is a universal primitive in the sense that you can construct those
RMW ops by speculatively computing the updated value and the CAS to
atomically update the value (in a retry loop). LL/SC also universal,
but different behavior. Both are not the same as an atomic op
performed deeper in the
well, yes. But that is the only atomic operation supported. No add, sub,
inc, xadd, bit operations
Le ven. 20 janv. 2017 à 14:31, Joe Savage a écrit :
> > I wonder what processor supports 128 bits atomics. As far as I know Intel
>
> > does not support it. Lock prefix is
> I wonder what processor supports 128 bits atomics. As far as I know Intel
> does not support it. Lock prefix is not allowed on SSE instructions.
Actually, Intel does support them through a locked cmpxchg16b. And ARMv8
through load exclusive pair and store exclusive pair.
I wonder what processor supports 128 bits atomics. As far as I know Intel
does not support it. Lock prefix is not allowed on SSE instructions.
FF
Le ven. 20 janv. 2017 à 13:59, Joe Savage a écrit :
> > Unfortunately, ODP atomics API does not support 128 bit atomics - at
>
> Unfortunately, ODP atomics API does not support 128 bit atomics - at least
> currently. So, your example could not use those anyway. Not all 64 CPUs
> have 128 bit atomic instructions.
Yes, this is unfortunate. For the time being I am using GCC's __atomic
operations such as
sts.linaro.org; Bill Fischofer <bill.fischo...@linaro.org>
> Cc: nd <n...@arm.com>
> Subject: Re: [lng-odp] 32-bit support in examples
>
> > Agree with Maxim. I which way the application is not 32 bit compliant?
>
> It uses 128-bit atomics, and so is really designed for exe
> Agree with Maxim. I which way the application is not 32 bit compliant?
It uses 128-bit atomics, and so is really designed for execution on 64-bit
machines. It is possible to provide lockless 32-bit support in this case,
though, and I have an implementation that does so. Since the pointer size
> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Maxim
> Uvarov
> Sent: Thursday, January 19, 2017 3:27 PM
> To: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] 32-bit support in examples
>
> On 01/19/17 16:23, J
On Thu, Jan 19, 2017 at 7:23 AM, Joe Savage wrote:
> Hey,
>
> I'm just finalising a patch to add a lock-free IPv4 fragmentation and
> reassembly example to ODP, and it has occurred to me that as the whole
> examples directory is compiled with odp-linux by default, I ought to
On 19 January 2017 at 09:37, Joe Savage wrote:
>> Is it a true very direct example of the concept, or more of a mini
>> application ?
>>
>> We are trying to lift out of examples those things that are more
>> complex mini apps to a new apps directory.
>> One distinction is the
> Is it a true very direct example of the concept, or more of a mini
> application ?
>
> We are trying to lift out of examples those things that are more
> complex mini apps to a new apps directory.
> One distinction is the requirement to use external traffic generation
> for example would likely
Joe,
Is it a true very direct example of the concept, or more of a mini application ?
We are trying to lift out of examples those things that are more
complex mini apps to a new apps directory.
One distinction is the requirement to use external traffic generation
for example would likely make it
On 01/19/17 16:23, Joe Savage wrote:
> Hey,
>
> I'm just finalising a patch to add a lock-free IPv4 fragmentation and
> reassembly example to ODP, and it has occurred to me that as the whole
> examples directory is compiled with odp-linux by default, I ought to be
> careful about supporting a
Hey,
I'm just finalising a patch to add a lock-free IPv4 fragmentation and
reassembly example to ODP, and it has occurred to me that as the whole
examples directory is compiled with odp-linux by default, I ought to be
careful about supporting a wide variety of platforms (ensuring that my change
22 matches
Mail list logo