Does not compile on aarch64

[JakkuSakura]

Removes corei7-avx related stuff in ffi/build.rs would solve the problem

warning: cc1: error: unknown value ‘corei7-avx’ for ‘-march’
warning: cc1: note: valid arguments are: armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a armv8.6-a armv8-r native

[zeeshanlakhani]

@qiujiangkun it's been something on our mind, i.e. running on arm, though we need to do more tests generally. From the build.rs perspective, I think we need to feature flag compile depending on the arch, which should be doable. We'll look into it.

@qiujiangkun did you test with an update to build.rs?

[JakkuSakura]

I'm stuck on another step. Seems I'm missing some modules in dpdk.

 /usr/bin/ld: cannot find -lrte_rawdev_ioat
 /usr/bin/ld: cannot find -lrte_pmd_sfc

[zeeshanlakhani]

@qiujiangkun yeah. we haven't tested on any arm setup/container, so the build file should/would be different. We'll def. put it on our list.

[JakkuSakura]

I have tried to compile these to components.
It's a bit weird
meson says

net/sfc:        only supported on x86_64
raw/ioat:       only supported on x86

however, Ubuntu has at least raw/ioat binary for arm64 https://launchpad.net/ubuntu/groovy/arm64/librte-rawdev-ioat20.0/19.11.4-1.
Also, it seems newer version of dpdk supports arm better

[JakkuSakura]

I have compiled it successfully, not tested yet.
On Ubuntu 20.04 LTS aarch64, after removing corei7-avx, I can compile capsule with

apt install dpdk-dev
export C_INCLUDE_PATH="/usr/include/dpdk/:/usr/include/aarch64-linux-gnu/dpdk/"
cargo build

Ubuntu automagically adapted dpdk 19.11.6 for aarch64, it's just awesome

[drunkirishcoder]

Right we don't officially have a arm based build process. A couple things we can do to move us towards better support for non x86-64 platform is

1. Make the march overridable without code changes. This is something we've wanted. The big challenge here is changing the rust side is very easy. but we build dpdk into the sandbox assuming the platform to be corei7. that gets a bit more difficult to untangle unless we start publishing different variants of the sandbox. Have to think that one through.

2. Don't hardcode the binaries we link to. Better to dynamically detect the list based on the output. That will guard us against dpdk changes or platform variances. Again though, it's contingent on figuring out how to compile dpdk correctly for the target platform.

[zeeshanlakhani]

To add to what @drunkirishcoder. It may be better to bite the bullet and build dpdk, via build.rs, as part of building capsule—making sure caching is in place if dpdk has been built already on the host. Essentially, we can just use a feature flag to build for ARM or X86.

Also, of note, putting this here for info: https://doc.dpdk.org/guides/linux_gsg/cross_build_dpdk_for_arm64.html