On Wed, Nov 11, 2015 at 03:40:15PM -0800, Alexei Starovoitov wrote:
> On Wed, Nov 11, 2015 at 11:21:35PM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 11, 2015 at 11:55:59AM -0800, Alexei Starovoitov wrote:
> > > Therefore things like memory barriers, full set of atomics are not
> > > applicable
>
On Wed, Nov 11, 2015 at 11:21:35PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 11, 2015 at 11:55:59AM -0800, Alexei Starovoitov wrote:
> > Therefore things like memory barriers, full set of atomics are not
> > applicable
> > in bpf world.
>
> There are still plenty of wait-free constructs one can
On Wed, Nov 11, 2015 at 11:55:59AM -0800, Alexei Starovoitov wrote:
> Therefore things like memory barriers, full set of atomics are not applicable
> in bpf world.
There are still plenty of wait-free constructs one can make using them.
Say a barrier/rendezvous construct for knowing when an event
On Wed, Nov 11, 2015 at 07:54:15PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 11, 2015 at 07:44:27PM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 11, 2015 at 07:31:28PM +0100, Peter Zijlstra wrote:
> > > > Add new one that does 'fetch_and_add' ? What is the real use case it
> > > > will be used for
On 11/11/2015 08:23 PM, Peter Zijlstra wrote:
On Wed, Nov 11, 2015 at 07:50:15PM +0100, Daniel Borkmann wrote:
Well, on that note, it's not like you just change the target to bpf in your
Makefile and can compile (& load into the kernel) anything you want with it.
You do have to write small, rest
On Wed, Nov 11, 2015 at 07:50:15PM +0100, Daniel Borkmann wrote:
> Well, on that note, it's not like you just change the target to bpf in your
> Makefile and can compile (& load into the kernel) anything you want with it.
> You do have to write small, restricted programs from scratch for a specific
From: Daniel Borkmann
Date: Wed, 11 Nov 2015 19:50:15 +0100
> Well, on that note, it's not like you just change the target to bpf
> in your Makefile and can compile (& load into the kernel) anything
> you want with it. You do have to write small, restricted programs
> from scratch for a specific
From: Alexei Starovoitov
Date: Wed, 11 Nov 2015 10:11:33 -0800
> bpf_xadd was never meant to be __sync_fetch_and_add equivalent.
> From the day one it meant to be atomic_add() as kernel does it.
+1
> I did piggy back on __sync in the llvm backend because it was the quick
> and dirty way to move
From: Will Deacon
Date: Wed, 11 Nov 2015 17:44:01 +
> On Wed, Nov 11, 2015 at 12:35:48PM -0500, David Miller wrote:
>> From: Alexei Starovoitov
>> Date: Wed, 11 Nov 2015 09:27:00 -0800
>>
>> > BPF_XADD == atomic_add() in kernel. period.
>> > we are not going to deprecate it or introduce som
On Wed, Nov 11, 2015 at 07:44:27PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 11, 2015 at 07:31:28PM +0100, Peter Zijlstra wrote:
> > > Add new one that does 'fetch_and_add' ? What is the real use case it
> > > will be used for?
> >
> > Look at all the atomic_{add,dec}_return*() users in the kerne
On 11/11/2015 07:31 PM, Peter Zijlstra wrote:
On Wed, Nov 11, 2015 at 10:11:33AM -0800, Alexei Starovoitov wrote:
On Wed, Nov 11, 2015 at 06:57:41PM +0100, Peter Zijlstra wrote:
On Wed, Nov 11, 2015 at 12:35:48PM -0500, David Miller wrote:
From: Alexei Starovoitov
Date: Wed, 11 Nov 2015 09:27
On Wed, Nov 11, 2015 at 10:11:33AM -0800, Alexei Starovoitov wrote:
> On Wed, Nov 11, 2015 at 06:57:41PM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 11, 2015 at 12:35:48PM -0500, David Miller wrote:
> > > From: Alexei Starovoitov
> > > Date: Wed, 11 Nov 2015 09:27:00 -0800
> > >
> > > > BPF_XADD
On Wed, Nov 11, 2015 at 07:31:28PM +0100, Peter Zijlstra wrote:
> > Add new one that does 'fetch_and_add' ? What is the real use case it
> > will be used for?
>
> Look at all the atomic_{add,dec}_return*() users in the kernel. A typical
> example would be a reader-writer lock implementations. See
On Wed, Nov 11, 2015 at 07:31:28PM +0100, Peter Zijlstra wrote:
> > Adding new intrinsic to llvm is not a big deal. I'll add it as soon
> > as I have time to work on it or if somebody beats me to it I would be
> > glad to test it and apply it.
>
> This isn't a speed coding contest. You want to thi
On Wed, Nov 11, 2015 at 10:11:33AM -0800, Alexei Starovoitov wrote:
> On Wed, Nov 11, 2015 at 06:57:41PM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 11, 2015 at 12:35:48PM -0500, David Miller wrote:
> > > From: Alexei Starovoitov
> > > Date: Wed, 11 Nov 2015 09:27:00 -0800
> > >
> > > > BPF_XADD
On Wed, Nov 11, 2015 at 06:57:41PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 11, 2015 at 12:35:48PM -0500, David Miller wrote:
> > From: Alexei Starovoitov
> > Date: Wed, 11 Nov 2015 09:27:00 -0800
> >
> > > BPF_XADD == atomic_add() in kernel. period.
> > > we are not going to deprecate it or in
On Wed, Nov 11, 2015 at 12:35:48PM -0500, David Miller wrote:
> From: Alexei Starovoitov
> Date: Wed, 11 Nov 2015 09:27:00 -0800
>
> > BPF_XADD == atomic_add() in kernel. period.
> > we are not going to deprecate it or introduce something else.
>
> Agreed, it makes no sense to try and tie C99 or
On Wed, Nov 11, 2015 at 12:35:48PM -0500, David Miller wrote:
> From: Alexei Starovoitov
> Date: Wed, 11 Nov 2015 09:27:00 -0800
>
> > BPF_XADD == atomic_add() in kernel. period.
> > we are not going to deprecate it or introduce something else.
>
> Agreed, it makes no sense to try and tie C99 or
From: Alexei Starovoitov
Date: Wed, 11 Nov 2015 09:27:00 -0800
> BPF_XADD == atomic_add() in kernel. period.
> we are not going to deprecate it or introduce something else.
Agreed, it makes no sense to try and tie C99 or whatever atomic
semantics to something that is already clearly defined to h
On Wed, Nov 11, 2015 at 04:23:41PM +, Will Deacon wrote:
>
> If we're going to document it, a bug tracker might be a good place to
> start. The behaviour, as it stands, is broken wrt the definition of the
> __sync primitives. That is, there is no way to build __sync_fetch_and_add
> out of BPF_
Hi Daniel,
Thanks for investigating this further.
On Wed, Nov 11, 2015 at 04:52:00PM +0100, Daniel Borkmann wrote:
> I played a bit around with eBPF code to assign the __sync_fetch_and_add()
> return value to a var and dump it to trace pipe, or use it as return code.
> llvm compiles it (with the
On 11/11/2015 01:58 PM, Peter Zijlstra wrote:
On Wed, Nov 11, 2015 at 12:38:31PM +, Will Deacon wrote:
Hmm, gcc doesn't have an eBPF compiler backend, so this won't work on
gcc at all. The eBPF backend in LLVM recognizes the __sync_fetch_and_add()
keyword and maps that to a BPF_XADD version
On Wed, Nov 11, 2015 at 12:38:31PM +, Will Deacon wrote:
> > Hmm, gcc doesn't have an eBPF compiler backend, so this won't work on
> > gcc at all. The eBPF backend in LLVM recognizes the __sync_fetch_and_add()
> > keyword and maps that to a BPF_XADD version (BPF_W or BPF_DW). In the
> > interpr
On Wed, Nov 11, 2015 at 01:21:04PM +0100, Daniel Borkmann wrote:
> On 11/11/2015 12:58 PM, Will Deacon wrote:
> >On Wed, Nov 11, 2015 at 11:42:11AM +0100, Daniel Borkmann wrote:
> >>On 11/11/2015 11:24 AM, Will Deacon wrote:
> >>>On Wed, Nov 11, 2015 at 09:49:48AM +0100, Arnd Bergmann wrote:
>
On 11/11/2015 12:58 PM, Will Deacon wrote:
On Wed, Nov 11, 2015 at 11:42:11AM +0100, Daniel Borkmann wrote:
On 11/11/2015 11:24 AM, Will Deacon wrote:
On Wed, Nov 11, 2015 at 09:49:48AM +0100, Arnd Bergmann wrote:
On Tuesday 10 November 2015 18:52:45 Z Lim wrote:
On Tue, Nov 10, 2015 at 4:42
Hi Daniel,
On Wed, Nov 11, 2015 at 11:42:11AM +0100, Daniel Borkmann wrote:
> On 11/11/2015 11:24 AM, Will Deacon wrote:
> >On Wed, Nov 11, 2015 at 09:49:48AM +0100, Arnd Bergmann wrote:
> >>On Tuesday 10 November 2015 18:52:45 Z Lim wrote:
> >>>On Tue, Nov 10, 2015 at 4:42 PM, Alexei Starovoitov
On 11/11/2015 11:24 AM, Will Deacon wrote:
On Wed, Nov 11, 2015 at 09:49:48AM +0100, Arnd Bergmann wrote:
On Tuesday 10 November 2015 18:52:45 Z Lim wrote:
On Tue, Nov 10, 2015 at 4:42 PM, Alexei Starovoitov
wrote:
On Tue, Nov 10, 2015 at 04:26:02PM -0800, Shi, Yang wrote:
On 11/10/2015 4:08
On Wed, Nov 11, 2015 at 09:49:48AM +0100, Arnd Bergmann wrote:
> On Tuesday 10 November 2015 18:52:45 Z Lim wrote:
> > On Tue, Nov 10, 2015 at 4:42 PM, Alexei Starovoitov
> > wrote:
> > > On Tue, Nov 10, 2015 at 04:26:02PM -0800, Shi, Yang wrote:
> > >> On 11/10/2015 4:08 PM, Eric Dumazet wrote:
>
On Tuesday 10 November 2015 18:52:45 Z Lim wrote:
> On Tue, Nov 10, 2015 at 4:42 PM, Alexei Starovoitov
> wrote:
> > On Tue, Nov 10, 2015 at 04:26:02PM -0800, Shi, Yang wrote:
> >> On 11/10/2015 4:08 PM, Eric Dumazet wrote:
> >> >On Tue, 2015-11-10 at 14:41 -0800, Yang Shi wrote:
> >> >>aarch64 do
Yang,
On Tue, Nov 10, 2015 at 4:42 PM, Alexei Starovoitov
wrote:
> On Tue, Nov 10, 2015 at 04:26:02PM -0800, Shi, Yang wrote:
>> On 11/10/2015 4:08 PM, Eric Dumazet wrote:
>> >On Tue, 2015-11-10 at 14:41 -0800, Yang Shi wrote:
>> >>aarch64 doesn't have native support for XADD instruction, impleme
On Tue, Nov 10, 2015 at 04:26:02PM -0800, Shi, Yang wrote:
> On 11/10/2015 4:08 PM, Eric Dumazet wrote:
> >On Tue, 2015-11-10 at 14:41 -0800, Yang Shi wrote:
> >>aarch64 doesn't have native support for XADD instruction, implement it by
> >>the below instruction sequence:
> >>
> >>Load (dst + off) t
On 11/10/2015 4:08 PM, Eric Dumazet wrote:
On Tue, 2015-11-10 at 14:41 -0800, Yang Shi wrote:
aarch64 doesn't have native support for XADD instruction, implement it by
the below instruction sequence:
Load (dst + off) to a register
Add src to it
Store it back to (dst + off)
Not really what is
On Tue, 2015-11-10 at 14:41 -0800, Yang Shi wrote:
> aarch64 doesn't have native support for XADD instruction, implement it by
> the below instruction sequence:
>
> Load (dst + off) to a register
> Add src to it
> Store it back to (dst + off)
Not really what is needed ?
See this BPF_XADD as an a
aarch64 doesn't have native support for XADD instruction, implement it by
the below instruction sequence:
Load (dst + off) to a register
Add src to it
Store it back to (dst + off)
Signed-off-by: Yang Shi
CC: Zi Shen Lim
CC: Xi Wang
---
arch/arm64/net/bpf_jit_comp.c | 19 +++
1
34 matches
Mail list logo
