As eBPF JIT support for arm32 was added recently with
commit 39c13c204bb1150d401e27d41a9d8b332be47c49, it seems appropriate to
add arm32 as arch with support for eBPF JIT in bpf and sysctl docs as well.
Signed-off-by: Shubham Bansal
---
Documentation/networking/filter.txt | 4
Hi David,
On Tue, Aug 22, 2017 at 10:02 PM, David Miller wrote:
>
> You posted this 4 times. :-(
>
> I hope I applied the right one.
All 4 of these are the same patch. I mistakenly sent it 4 times. My
apologies for that.
>
> Go check net-next and please send me any necessary fix up patches.
I ju
Please ignore this mail. Sent it by mistake.
Sent the correct patch later on.
Please ignore this mail. Sent it by mistake.
Russell, David, Alexei, Daniel and Kees. Please check this patch and
lets finish it.
Thanks.
space to emulate 64 bit eBPF ISA on 32 bit
ARM because of deficiency of general purpose registers on ARM. Currently,
only LITTLE ENDIAN machines are supported in this eBPF JIT Compiler.
Tested on ARMv7 with QEMU by me (Shubham Bansal).
Testing results on ARMv7:
1) test_bpf: Summary: 341 PASSED, 0
space to emulate 64 bit eBPF ISA on 32 bit
ARM because of deficiency of general purpose registers on ARM. Currently,
only LITTLE ENDIAN machines are supported in this eBPF JIT Compiler.
Tested on ARMv7 with QEMU by me (Shubham Bansal).
Testing results on ARMv7:
1) test_bpf: Summary: 341 PASSED, 0
space to emulate 64 bit eBPF ISA on 32 bit
ARM because of deficiency of general purpose registers on ARM. Currently,
only LITTLE ENDIAN machines are supported in this eBPF JIT Compiler.
Tested on ARMv7 with QEMU by me (Shubham Bansal).
Testing results on ARMv7:
1) test_bpf: Summary: 341 PASSED, 0
space to emulate 64 bit eBPF ISA on 32 bit
ARM because of deficiency of general purpose registers on ARM. Currently,
only LITTLE ENDIAN machines are supported in this eBPF JIT Compiler.
Tested on ARMv7 with QEMU by me (Shubham Bansal).
Testing results on ARMv7:
1) test_bpf: Summary: 341 PASSED, 0
> With the below #ifdef __LITTLE_ENDIAN spanning the entire
> bpf_int_jit_compile(), a user can then enable and compile
> eBPF JIT for big endian, even set the bpf_jit_enable to 1
> to turn it on, but it won't JIT anything, which is contrary
> to the expectation.
>
> This should rather be a hard de
> Acked-by: Alexei Starovoitov
David, Russell, Kees and Daniel, Anything from your side? Is this
patch ready to land in net-next?
total map id found by get_next_id 0 nsec
test_pkt_md_access:PASS: 30459 nsec<--- Here is the difference.
Summary: 30 PASSED, 0 FAILED
On Sun, Aug 20, 2017 at 2:58 AM, Shubham Bansal
wrote:
> Here are numbers.
>
> Without any JIT enabled
>
> test_pkt_access:PASS:ipv4 1823 n
Here are numbers.
Without any JIT enabled
test_pkt_access:PASS:ipv4 1823 nsec
test_pkt_access:PASS:ipv6 1743 nsec
test_xdp:PASS:ipv4 769022 nsec
test_xdp:PASS:ipv6 15408 nsec
test_l4lb:PASS:ipv4 12441 nsec
test_l4lb:PASS:ipv6 18131 nsec
test_tcp_estats:PASS: 0 nsec
test_bpf_obj_id:PASS:get-fd-by-
One more thing I forgot to mention.
I think this is the first implementation of eBPF JIT on any 32 bit
arch, correct me if I am wrong. I think we can use this as a POC to
implement eBPF on other 32 bit arch as well like x86, depends on its
need I guess.
> impressive work.
> Acked-by: Alexei Starovoitov
Thanks :)
I can't take all the credit. It was Daniel and Kees who helped me a lot.
I would have given up a long time ago without them.
>
> Any performance numbers with vs without JIT ?
Here is the mail from Kees on v1 of the patch.
For what it'
htab inlining more robust wrt assumptions"
with message ID:
03f4e86a029058d0f674fd9bf288e55a5ec07df3.1503104831.git.dan...@iogearbox.net
Tested on ARMv7 with QEMU by me (Shubham Bansal).
Testing results on ARMv7:
1) test_bpf: Summary: 341 PASSED, 0 FAILED, [312/333 JIT'ed]
2) test_tag: OK
Okay Kees. I will take a look at it.
Best,
Shubham Bansal
On Fri, Jul 7, 2017 at 10:12 AM, Kees Cook wrote:
> On Wed, Jul 5, 2017 at 8:49 PM, Shubham Bansal
> wrote:
>> Hi Kees,
>>
>> Problem is my ARM machine don't have clang and iproute2 which is
>> keeping
Hi Kees,
Problem is my ARM machine don't have clang and iproute2 which is
keeping me from testing the bpf tail calls.
You should do the following to test it,.
1. tools/testing/selftests/bpf/
2. make
3. sudo ./test_progs
And, before testing, you have to do "make headers_install".
These tests are
Hi Russell,Daniel and Kees,
I am attaching the latest patch with this mail. It included support
for BPF_CALL | BPF_JMP tested with and without constant blinding on
ARMv7 machine.
Due to the limitation on my machine I can't test the tail call. It
would be a great help if any of you could help me wi
then do let me know what more is
required?
Best,
Shubham Bansal
On Wed, Jun 21, 2017 at 10:02 PM, Daniel Borkmann wrote:
> On 06/21/2017 04:26 PM, Shubham Bansal wrote:
> [...]
>>
>> So ultimately, we call helper_function which takes u64 as arguments
>> only. I know
Hi Daniel,
>
> So my question would be, why can't the JIT imitate something
> similar to what we do in the interpreter as well? So looking
> at the disasm of what gcc compiles for the interpreter when it's
> doing the above call could help as well in going forward. Not
> sure if that answers your
Hi Daniel,
>
> Sorry, had a travel over the weekend, so didn't read it in time.
>
> What is the issue with imitating in JIT what the interpreter is
> doing as a starting point? That should be generic enough to handle
> any case.
>
> Otherwise you'd need some sort of reverse mapping since verifier
Hi Daniel,
>
> Not all of the helpers have 4 or less byte arguments only, there are a
> few with 8 byte arguments, so making that general assumption wouldn't
> work. I guess what could be done is that helpers have a flag in struct
> bpf_func_proto which indicates for JITs that all args are 4 byte
Hi Daniel, Kees, David, Russel,
>> Any plans to implement above especially BPF_JMP | BPF_CALL in near future?
>> Reason why I'm asking is that i) currently the arm32 cBPF JIT implements
>> all of the cBPF extensions (except SKF_AD_RANDOM and SKF_AD_VLAN_TPID).
>> Some of the programs that were JIT
t;> Implementation is using scratch space to emulate 64 bit eBPF ISA on 32
>>> bit
>>> ARM because of deficiency of general purpose registers on ARM. Currently,
>>> only LITTLE ENDIAN machines are supported in this eBPF JIT Compiler.
>>>
>>> Tested on
Hi Russel,
On Mon, Jun 12, 2017 at 4:36 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 12, 2017 at 12:21:03PM +0200, Daniel Borkmann wrote:
>> On 05/30/2017 09:19 PM, Kees Cook wrote:
>> >On Thu, May 25, 2017 at 4:13 PM, Shubham Bansal
>> > wrote:
>> >>+
Hi Russell, Alexei, David, Daniel, kees,
Any update on this patch moving forward?
Best,
Shubham Bansal
On Wed, May 31, 2017 at 12:49 AM, Kees Cook wrote:
> Forwarding this to net-dev and eBPF folks, who weren't on CC...
>
> -Kees
>
> On Thu, May 25, 2017 at 4:13 PM, Shu
Hi Kees, Daniel, Mircea and David,
Here is the patch I sent to the arm mailing list.
Any Comments are welcome.
-- Forwarded message --
From: Shubham Bansal
Date: Wed, May 24, 2017 at 12:03 AM
Subject: [PATCH] RFC: arm: eBPF JIT compiler
To: li...@armlinux.org.uk
Cc: linux-arm
Hi Kees,
I already have ARMv5 and ARMv6 code written. I just haven't tested it
yet. Should i send the patch with those as well ?
Best,
Shubham Bansal
On Tue, May 23, 2017 at 9:52 AM, Kees Cook wrote:
> On Mon, May 22, 2017 at 8:34 PM, Shubham Bansal
> wrote:
>> I would post
Hi Florian,
>> I think it is fine to only target ARMv7. It is harder and harder to
>> find devices on v5 or v6 CPUs that would want to be using BPF JIT,
>> IMO.
>
> There are still a ton of Marvell-based routers out there (e.g: Kirkwood,
> Orion5x) that are ARMv5 and that prompted Nicholas (hey th
:c0308424 r7:0080
r6:756e694c r5:00156a18
[ 92.312277] r4:
[ 93.835343] 1065840 PASS
Does this look like a bug? I will send the separate mail if it does.
Let me know.
Best,
Shubham Bansal
On Tue, May 23, 2017 at 1:35 AM, Kees Cook wrote:
> On Mon, May 22, 2017 at 10:04
Hi Daniel,
Here are the benchmarks.
1) Interpreter:
[root@vexpress modules]# insmod test_bpf.ko
[ 37.244999] test_bpf: #0 TAX jited:0 757 645 650 PASS
[ 37.272577] test_bpf: #1 TXA jited:0 366 334 336 PASS
[ 37.283507] test_bpf: #2 ADD_SUB_MUL_K jited:0 543 PASS
[ 37.289542] test_bpf: #3
[ 63.807447] test_bpf: #311 MOD default A jited:1 270 PASS
[ 63.810667] test_bpf: #312 JMP EQ default A jited:1 94 PASS
[ 63.812321] test_bpf: #313 JMP EQ default X jited:1 163 PASS
[ 63.814754] test_bpf: Summary: 314 PASSED, 0 FAILED, [278/306 JIT'ed]
Let me know if you need more inf
Finally finished testing.
"test_bpf: Summary: 314 PASSED, 0 FAILED, [274/306 JIT'ed]"
Will send the patch after code refactoring. Thanks for all the help
you guys. I really really appreciate it.
Special thanks to Kees and Daniel. :)
Best,
Shubham Bansal
On Thu, May 11, 2017 a
the low 32 bit in registers and high 32
bit in scratch memory?
"""
What do you guys suggest i should implement it? I am almost done with
my current implementation but if you think I should change it to the
way David suggested, its better to suggest now before I send the
patch.
Let me
e a36398923b914fe2 ]---
Segmentation fault
Why is trying to execute TAX which is a cBPF instruction?
Best,
Shubham Bansal
On Thu, Apr 6, 2017 at 6:21 PM, Daniel Borkmann wrote:
> On 04/06/2017 01:05 PM, Shubham Bansal wrote:
>>
>> Gentle Reminder.
>
>
> Sorry for
Okay. My mistake. I just checked the verify function.
Apologies.
Best,
Shubham Bansal
On Sun, May 7, 2017 at 1:57 AM, Shubham Bansal
wrote:
> Thanks David.
>
> Hi all,
>
> I have two questions about the code at arch/arm64/net/bpf_jit_comp.c.
>
> 1. At line 708, &q
as an index of that array. Shouldn't it be be
arithmetic left shifted by 3 or multiplied by 8 to get the right
address in that array of pointers ?
Apologies if any of the above question is stupid to ask.
Best,
Shubham
Best,
Shubham Bansal
On Sun, May 7, 2017 at 12:08 AM, David Miller wrot
where I could find the description of these
instructions please?
Best,
Shubham Bansal
On Thu, Apr 6, 2017 at 6:21 PM, Daniel Borkmann wrote:
> On 04/06/2017 01:05 PM, Shubham Bansal wrote:
>>
>> Gentle Reminder.
>
>
> Sorry for late reply.
>
>> Anybody can tel
Gentle Reminder.
Anybody can tell me how to test the JIT compiler ?
Best,
Shubham Bansal
On Thu, Mar 30, 2017 at 7:34 PM, Shubham Bansal
wrote:
> Thanks Daniel.
>
> Can you tell me how to test the eBPF JIT compiler? It would be great
> if you could tell me starting from compili
Thanks Daniel.
Can you tell me how to test the eBPF JIT compiler? It would be great
if you could tell me starting from compiling to proper testing.
Best,
Shubham Bansal
On Wed, Mar 29, 2017 at 5:30 AM, Daniel Borkmann wrote:
> Hi Shubham,
>
> On 03/28/2017 10:49 PM, Shubham Ban
your presentations. I just need a very
general idea. May be you know the code in kernel where it is
implemented.
Thanks for the help Daniel.
Best,
Shubham Bansal
On Thu, Mar 16, 2017 at 3:25 AM, David Miller wrote:
> From: Shubham Bansal
> Date: Wed, 15 Mar 2017 17:43:44 +0530
>
>>>
Hi kees,
> It seems like you're suggesting truncating the 64-bit register values?
> I think your best solution is going to be to use a memory scratch
> space and build 64-bit operations using 32-bit registers and memory
> operations.
Yes. I was suggesting the truncating of 64-bit register values,
Anybody willing to take swing at my following comments ?
On Wed, Feb 1, 2017 at 6:31 PM, Shubham Bansal
wrote:
> Hi Kees & Daniel,
>
> On Tue, Jan 31, 2017 at 09:44:56AM -0800, Kees Cook wrote:
>> >> > 1.) Currently, as eBPF uses 64 bit registers, I am mapping 64 bit
JIT mostly depends on 1-to-1 mapping of
> >> > its instructions with native instructions.
> >>
> >> I don't know -- it might be tricky with needing to deal with 64-bit
> >> registers. But if you can make it faster than the non-JIT, it should
> >> be a win. :) Yay assembly.
Well, As I mentioned above about my thinking towards the implementation,
I am not sure it would be faster than non-JIT or even correct for that matter.
It might be but I don't think I have enough knowledge to benchmark the
implementation as of now.
-Shubham Bansal
Hi Nick,
On Thu, Feb 2, 2017 at 12:59 PM, nick viljoen
wrote:
> Hey Shubham,
>
> I have been doing some similar work-might be worth pooling
> resource if there is interest?
Sure. That sounds great.
>
> We made a presentation at the previous netdev conference about
> what we are doing-you can ch
it should
> >> be a win. :) Yay assembly.
Well, As I mentioned above about my thinking towards the implementation,
I am not sure it would be faster than non-JIT or even correct for that matter.
It might be but I don't think I have enough knowledge to benchmark the
implementation as of now.
-Shubham Bansal
gt;> I don't know -- it might be tricky with needing to deal with 64-bit
> >> registers. But if you can make it faster than the non-JIT, it should
> >> be a win. :) Yay assembly.
Well, As I mentioned above about my thinking towards the implementation,
I am not sure it would be faster than non-JIT or even correct for that matter.
It might be but I don't think I have enough knowledge to benchmark the
implementation as of now.
-Shubham Bansal
apping good enough to make the JIT fast enough ?
because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
its instructions with native instructions.
Appreciate the help from anybody from the mailing list.
Best,
Shubham Bansal
49 matches
Mail list logo
