On 02/14/2014 06:55 PM, Alexei Starovoitov wrote:
On Fri, Feb 14, 2014 at 9:02 AM, Daniel Borkmann wrote:
On 02/14/2014 01:59 AM, Alexei Starovoitov wrote:
...
I'm very curious, do you also have any performance numbers, e.g. for
networking by taking JIT'ed/non-JIT'ed BPF filters and compare
On 02/14/2014 06:55 PM, Alexei Starovoitov wrote:
On Fri, Feb 14, 2014 at 9:02 AM, Daniel Borkmann dbork...@redhat.com wrote:
On 02/14/2014 01:59 AM, Alexei Starovoitov wrote:
...
I'm very curious, do you also have any performance numbers, e.g. for
networking by taking JIT'ed/non-JIT'ed BPF
On Fri, Feb 14, 2014 at 9:27 AM, Daniel Borkmann wrote:
> On 02/14/2014 05:47 AM, Alexei Starovoitov wrote:
> ...
>>>
>>> Do you see a possibility to integrate your work step by step? That is,
>>
>>
>> Sure. let's see how we can do it.
>>
>>> to first integrate the interpreter part only; meaning,
On Fri, Feb 14, 2014 at 9:02 AM, Daniel Borkmann wrote:
> On 02/14/2014 01:59 AM, Alexei Starovoitov wrote:
> ...
>>>
>>> I'm very curious, do you also have any performance numbers, e.g. for
>>>
>>> networking by taking JIT'ed/non-JIT'ed BPF filters and compare them
>>> against
>>>
On 02/14/2014 05:47 AM, Alexei Starovoitov wrote:
...
Do you see a possibility to integrate your work step by step? That is,
Sure. let's see how we can do it.
to first integrate the interpreter part only; meaning, to detect "old"
BPF programs e.g. coming from SO_ATTACH_FILTER et al and run
On 02/14/2014 01:59 AM, Alexei Starovoitov wrote:
...
I'm very curious, do you also have any performance numbers, e.g. for
networking by taking JIT'ed/non-JIT'ed BPF filters and compare them against
JIT'ed/non-JIT'ed eBPF filters to see how many pps we gain or loose e.g.
for a scenario with a
On 02/14/2014 01:59 AM, Alexei Starovoitov wrote:
...
I'm very curious, do you also have any performance numbers, e.g. for
networking by taking JIT'ed/non-JIT'ed BPF filters and compare them against
JIT'ed/non-JIT'ed eBPF filters to see how many pps we gain or loose e.g.
for a scenario with a
On 02/14/2014 05:47 AM, Alexei Starovoitov wrote:
...
Do you see a possibility to integrate your work step by step? That is,
Sure. let's see how we can do it.
to first integrate the interpreter part only; meaning, to detect old
BPF programs e.g. coming from SO_ATTACH_FILTER et al and run
On Fri, Feb 14, 2014 at 9:02 AM, Daniel Borkmann dbork...@redhat.com wrote:
On 02/14/2014 01:59 AM, Alexei Starovoitov wrote:
...
I'm very curious, do you also have any performance numbers, e.g. for
networking by taking JIT'ed/non-JIT'ed BPF filters and compare them
against
On Fri, Feb 14, 2014 at 9:27 AM, Daniel Borkmann dbork...@redhat.com wrote:
On 02/14/2014 05:47 AM, Alexei Starovoitov wrote:
...
Do you see a possibility to integrate your work step by step? That is,
Sure. let's see how we can do it.
to first integrate the interpreter part only; meaning,
On Thu, Feb 13, 2014 at 12:20 PM, Daniel Borkmann wrote:
> On 02/07/2014 02:20 AM, Alexei Starovoitov wrote:
> ...
>>
>> Hi Daniel,
>
>
> Thanks for your answer and sorry for the late reply.
>
>
>> Thank you for taking a look. Good questions. I had the same concerns.
>> Old BPF was carefully
On Thu, Feb 13, 2014 at 2:22 PM, Daniel Borkmann wrote:
> On 02/13/2014 09:20 PM, Daniel Borkmann wrote:
>>
>> On 02/07/2014 02:20 AM, Alexei Starovoitov wrote:
>> ...
>>>
>>> Hi Daniel,
>>
>>
>> Thanks for your answer and sorry for the late reply.
>>
>>> Thank you for taking a look. Good
On 02/13/2014 11:47 PM, H. Peter Anvin wrote:
On 02/13/2014 02:44 PM, Daniel Borkmann wrote:
Well, if that would be the case, then seccomp would have had JIT support
long ago. ;-) Right now BPF filters with seccomp are not JIT compiled
for _any_ architecture.
Really, I was under the
On 02/13/2014 02:44 PM, Daniel Borkmann wrote:
>
> Well, if that would be the case, then seccomp would have had JIT support
> long ago. ;-) Right now BPF filters with seccomp are not JIT compiled
> for _any_ architecture.
>
Really, I was under the impression there were. They *should be*, that
On 02/13/2014 11:32 PM, H. Peter Anvin wrote:
On 02/06/2014 05:20 PM, Alexei Starovoitov wrote:
I believe that old BPF outlived itself and BPF64 should
replace it in all current use cases plus a lot more.
It just cannot happen at once.
BPF64 can come in. bpf32->bpf64 converter functioning.
JIT
On 02/06/2014 05:20 PM, Alexei Starovoitov wrote:
>
> I believe that old BPF outlived itself and BPF64 should
> replace it in all current use cases plus a lot more.
> It just cannot happen at once.
> BPF64 can come in. bpf32->bpf64 converter functioning.
> JIT from bpf64->aarch64 and may be
On 02/13/2014 09:20 PM, Daniel Borkmann wrote:
On 02/07/2014 02:20 AM, Alexei Starovoitov wrote:
...
Hi Daniel,
Thanks for your answer and sorry for the late reply.
Thank you for taking a look. Good questions. I had the same concerns.
Old BPF was carefully extended in specific places.
End
On 02/07/2014 02:20 AM, Alexei Starovoitov wrote:
...
Hi Daniel,
Thanks for your answer and sorry for the late reply.
Thank you for taking a look. Good questions. I had the same concerns.
Old BPF was carefully extended in specific places.
End result may look big at first glance, but every
On 02/07/2014 02:20 AM, Alexei Starovoitov wrote:
...
Hi Daniel,
Thanks for your answer and sorry for the late reply.
Thank you for taking a look. Good questions. I had the same concerns.
Old BPF was carefully extended in specific places.
End result may look big at first glance, but every
On 02/13/2014 09:20 PM, Daniel Borkmann wrote:
On 02/07/2014 02:20 AM, Alexei Starovoitov wrote:
...
Hi Daniel,
Thanks for your answer and sorry for the late reply.
Thank you for taking a look. Good questions. I had the same concerns.
Old BPF was carefully extended in specific places.
End
On 02/06/2014 05:20 PM, Alexei Starovoitov wrote:
I believe that old BPF outlived itself and BPF64 should
replace it in all current use cases plus a lot more.
It just cannot happen at once.
BPF64 can come in. bpf32-bpf64 converter functioning.
JIT from bpf64-aarch64 and may be sparc64 needs
On 02/13/2014 11:32 PM, H. Peter Anvin wrote:
On 02/06/2014 05:20 PM, Alexei Starovoitov wrote:
I believe that old BPF outlived itself and BPF64 should
replace it in all current use cases plus a lot more.
It just cannot happen at once.
BPF64 can come in. bpf32-bpf64 converter functioning.
JIT
On 02/13/2014 02:44 PM, Daniel Borkmann wrote:
Well, if that would be the case, then seccomp would have had JIT support
long ago. ;-) Right now BPF filters with seccomp are not JIT compiled
for _any_ architecture.
Really, I was under the impression there were. They *should be*, that
was
On 02/13/2014 11:47 PM, H. Peter Anvin wrote:
On 02/13/2014 02:44 PM, Daniel Borkmann wrote:
Well, if that would be the case, then seccomp would have had JIT support
long ago. ;-) Right now BPF filters with seccomp are not JIT compiled
for _any_ architecture.
Really, I was under the
On Thu, Feb 13, 2014 at 2:22 PM, Daniel Borkmann dbork...@redhat.com wrote:
On 02/13/2014 09:20 PM, Daniel Borkmann wrote:
On 02/07/2014 02:20 AM, Alexei Starovoitov wrote:
...
Hi Daniel,
Thanks for your answer and sorry for the late reply.
Thank you for taking a look. Good questions. I
On Thu, Feb 13, 2014 at 12:20 PM, Daniel Borkmann dbork...@redhat.com wrote:
On 02/07/2014 02:20 AM, Alexei Starovoitov wrote:
...
Hi Daniel,
Thanks for your answer and sorry for the late reply.
Thank you for taking a look. Good questions. I had the same concerns.
Old BPF was carefully
On Thu, Feb 6, 2014 at 2:42 AM, Daniel Borkmann wrote:
> Hi Alexei,
>
>
> On 02/06/2014 02:10 AM, Alexei Starovoitov wrote:
>>
>> Hi All,
>>
>> this patch set addresses main sticking points of the previous discussion:
>> http://thread.gmane.org/gmane.linux.kernel/1605783
>>
>> Main difference:
>>
Hi Alexei,
On 02/06/2014 02:10 AM, Alexei Starovoitov wrote:
Hi All,
this patch set addresses main sticking points of the previous discussion:
http://thread.gmane.org/gmane.linux.kernel/1605783
Main difference:
. all components are now in one place
tools/bpf/llvm - standalone LLVM backend
Hi Alexei,
On 02/06/2014 02:10 AM, Alexei Starovoitov wrote:
Hi All,
this patch set addresses main sticking points of the previous discussion:
http://thread.gmane.org/gmane.linux.kernel/1605783
Main difference:
. all components are now in one place
tools/bpf/llvm - standalone LLVM backend
On Thu, Feb 6, 2014 at 2:42 AM, Daniel Borkmann dbork...@redhat.com wrote:
Hi Alexei,
On 02/06/2014 02:10 AM, Alexei Starovoitov wrote:
Hi All,
this patch set addresses main sticking points of the previous discussion:
http://thread.gmane.org/gmane.linux.kernel/1605783
Main difference:
Hi All,
this patch set addresses main sticking points of the previous discussion:
http://thread.gmane.org/gmane.linux.kernel/1605783
Main difference:
. all components are now in one place
tools/bpf/llvm - standalone LLVM backend for extended BPF instruction set
. regs.si, regs.di accessors
On Wed, Feb 5, 2014 at 4:27 PM, David Miller wrote:
>
> From: Alexei Starovoitov
> Date: Wed, 5 Feb 2014 16:10:00 -0800
>
> > this patch set addresses main sticking points of the previous discussion:
> > http://thread.gmane.org/gmane.linux.kernel/1605783
>
> You really need to properly CC:
From: Alexei Starovoitov
Date: Wed, 5 Feb 2014 16:10:00 -0800
> this patch set addresses main sticking points of the previous discussion:
> http://thread.gmane.org/gmane.linux.kernel/1605783
You really need to properly CC: netdev on this patch series.
--
To unsubscribe from this list: send the
Hi All,
this patch set addresses main sticking points of the previous discussion:
http://thread.gmane.org/gmane.linux.kernel/1605783
Main difference:
. all components are now in one place
tools/bpf/llvm - standalone LLVM backend for extended BPF instruction set
. regs.si, regs.di accessors
Hi All,
this patch set addresses main sticking points of the previous discussion:
http://thread.gmane.org/gmane.linux.kernel/1605783
Main difference:
. all components are now in one place
tools/bpf/llvm - standalone LLVM backend for extended BPF instruction set
. regs.si, regs.di accessors
From: Alexei Starovoitov a...@plumgrid.com
Date: Wed, 5 Feb 2014 16:10:00 -0800
this patch set addresses main sticking points of the previous discussion:
http://thread.gmane.org/gmane.linux.kernel/1605783
You really need to properly CC: netdev on this patch series.
--
To unsubscribe from this
On Wed, Feb 5, 2014 at 4:27 PM, David Miller da...@redhat.com wrote:
From: Alexei Starovoitov a...@plumgrid.com
Date: Wed, 5 Feb 2014 16:10:00 -0800
this patch set addresses main sticking points of the previous discussion:
http://thread.gmane.org/gmane.linux.kernel/1605783
You really
Hi All,
this patch set addresses main sticking points of the previous discussion:
http://thread.gmane.org/gmane.linux.kernel/1605783
Main difference:
. all components are now in one place
tools/bpf/llvm - standalone LLVM backend for extended BPF instruction set
. regs.si, regs.di accessors
38 matches
Mail list logo
