Cross-compilation to Arm64

[egorse]

Looking for hints howto cross-compile for arm64. Any advice?

Thanks!

[gshimansky]

If you get DPDK to build on arm, everything else is easy. Go is cross platform and should work out of the box. Native C code uses intrinsics which I suppose exist on arm too. Let us know how it does, maybe I can give you some advice if you encounter a problem.

[egorse]

@gshimansky so far I tried armv7 (cause just had cross compilers under the hands - armv8 is next) - the DPDK kinda simple but mlx, numa and kni cause some minor troubles (kni is disabled for armv7 by default but needed for nff-go); had to skip pktgen cause it was taking lua from host. AVX/AVX2 detected from build host.

The nff-go right away hit problem with asm/asm.s being x86_64 only. Then next is internal/low/low.{go|h} due to __m128. Both seems will be a problem for armv8 (arm64) too (not sure on neon).

[egorse]

After dpdk is build, pktgen skipped (modified Makefile), stub asm/asm.go, then GOARCH=arm64 make [NFF_GO_NO_MLX_DRIVERS=y] with/without mlx returns:

go build github.com/intel-go/nff-go/internal/low: build constraints exclude all Go files in /home/egorse/projects/nff-go/internal/low
../../../mk/leaf.mk:19: recipe for target 'testMerge' failed
make[3]: *** [testMerge] Error 1

Which is odd - my go is 1.13.5. Any advice?

[egorse]

The problem is cgo is disabled when cross-compiling. The GOARCH=arm64 CGO_ENABLED=1 CROSS_COMPILE=aarch64-linux-gnu- CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ NFF_GO_NO_MLX_DRIVERS=yes NFF_GO_NO_BPF_SUPPORT=yes make -j10 kinda works until hit __m128.

Fails on __m128:

# github.com/intel-go/nff-go/internal/low
In file included from ../../../internal/low/low.go:16:0:
./low.h:159:1: error: unknown type name '__m128'; did you mean '__f128'?
 __m128 zero128 = {0, 0, 0, 0};
 ^~~~~~

[egorse]

@gshimansky I wonder - I can not find how the zero128 from low.h is referenced? Is that by some library or its just "dead code"? Or is it equivalent of go's compilation time interface validation?

The real "problems" is low.s. The examples/ipsec/crypto_mb has also *.s too but that's in examples, so might ~skipped.

[gshimansky]

Yes it is not referenced anywhere. There used to be an SSE/AVX optimization with zeroing parts of mbuf, but apparently this code is no longer present. You can safely comment out these variable declarations.