[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0aab1aec-814c-e496-4254-ca33a81f8c7f@fb.com>
Date: Thu, 11 May 2017 22:07:04 -0700
From: Alexei Starovoitov <ast@...com>
To: David Miller <davem@...emloft.net>
CC: <daniel@...earbox.net>, <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] selftests/bpf: get rid of -D__x86_64__
On 5/11/17 6:29 PM, David Miller wrote:
> This whole thing go me thinking however. What do you expect to happen
> on 32-bit architectures implementing an eBPF JIT?
I doubt any 32-bit cpu architectures will do JIT in the near future.
Doing 64-bit operations everywhere is too painful in assembler.
HW offloading is a different story. Like nfp has 32-bit registers
and everything 64-bit in bpf is not the ideal for them.
For such cases the idea is to teach verifier to recognize that
registers don't use upper 32-bits and mark them, so JITs can be
more efficient.
> That's going to
> create some serious conflicts and consternation wrt. tracing which is
> going to want to use headers which are for sizeof(void *)==4 whereas
> for eBPF natively it's 8.
that is indeed a problem. The bpf tracing approach that includes
kernel headers mostly doesn't work on 32-bit archs, though
few iovisor/bcc scripts should be functional. Those that don't
walk pointers and relying on tracepoints instead.
Powered by blists - more mailing lists