[net-next] selftests/bpf: get rid of -D__x86_64__

From: Alexei Starovoitov <ast@fb.com>
Date: Thu, 4 May 2017 16:34:08 -0700

> Hence I think the cleanest solution is to have bpf arch's types.h
> either installed with llvm/gcc or picked from selftests's dir.

Something like this?

On 5/11/17 12:02 PM, David Miller wrote:
> From: Alexei Starovoitov <ast@fb.com>
> Date: Thu, 4 May 2017 16:34:08 -0700
>
>> Hence I think the cleanest solution is to have bpf arch's types.h
>> either installed with llvm/gcc or picked from selftests's dir.
>
> Something like this?

yes :)
Ack.

> ====================
> [PATCH] bpf: Provide a linux/types.h override for bpf selftests.
>
> We do not want to use the architecture's type.h header when
> building BPF programs which are always 64-bit.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>  tools/testing/selftests/bpf/Makefile                   | 3 ++-
>  tools/testing/selftests/bpf/include/uapi/linux/types.h | 6 ++++++
>  2 files changed, 8 insertions(+), 1 deletion(-)
>  create mode 100644 tools/testing/selftests/bpf/include/uapi/linux/types.h
>
> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index f92f27d..f389b02 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -35,6 +35,7 @@ $(BPFOBJ): force
>  CLANG ?= clang
>
>  %.o: %.c
> -	$(CLANG) -I. -I../../../include/uapi -I../../../../samples/bpf/ \
> +	$(CLANG) -I. -I./include/uapi -I../../../include/uapi \

Can we than move gnu/stubs.h into include/uapi as well and remove
the first -I. ?
Or keep them separate, since this linux/types.h is bpf's arch types.h
whereas gnu/stubs.h is a hack for glibc /usr/include/features.h ?
I'm fine whichever way including keeping this patch as-is.

From: Alexei Starovoitov <ast@fb.com>
Date: Thu, 11 May 2017 15:58:33 -0700

> Can we than move gnu/stubs.h into include/uapi as well and remove
> the first -I. ?
> Or keep them separate, since this linux/types.h is bpf's arch types.h
> whereas gnu/stubs.h is a hack for glibc /usr/include/features.h ?
> I'm fine whichever way including keeping this patch as-is.

Let's keep it like this for now, and perhaps in the long term we
can have a better more organized piece of infrastructure for this.

So I'll commit this fix for now and happily sparc now works out of the
box for all the selftests and samples as far as I can tell. :-)

This whole thing go me thinking however.  What do you expect to happen
on 32-bit architectures implementing an eBPF JIT?  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.

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.

From: Alexei Starovoitov <ast@fb.com>
Date: Thu, 11 May 2017 22:07:04 -0700

> 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.

ARM 32-bit is being implemented as we speak, in fact it's been discussed
on this very list over the past week.

On Fri, May 12, 2017 at 10:46:24AM -0400, David Miller wrote:
> From: Alexei Starovoitov <ast@fb.com>
> Date: Thu, 11 May 2017 22:07:04 -0700
> 
> > 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.
> 
> ARM 32-bit is being implemented as we speak, in fact it's been discussed
> on this very list over the past week.

It could be XDP is interesting on small embedded systems, i.e ARM32
and MIPS, used in WiFi access points and the like. I've heard it said
that the Linux network stack has become too big to run well on these
systems, it no longer fits in the instruction cache. It would be
interesting to see if XDP/eBPF can be used for handling part of the
packet load without thrashing the instruction cache.

       Andrew