On 5/18/2021 4:15 PM, Bruce Richardson wrote:

On Tue, May 18, 2021 at 03:40:18PM +0100, Ferruh Yigit wrote:

quoted

On 5/14/2021 10:53 AM, Chengwen Feng wrote:

quoted

Currently, the SVE code is compiled only when -march supports SVE
(e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
approach.

The solution:
a. If the minimum instruction set support SVE then compiles it.
b. Else if the compiler support SVE then compiles it.
c. Otherwise don't compile it.

[1] https://mails.dpdk.org/archives/dev/2021-April/208189.html

Hi Chengwen,

As far as I understand from above problem statement, you want to produce a
binary that can run in two different platforms, one supports only NEON
instructions, other supports NEON + SVE.

For this driver should be compiled in a way to support min instruction set,
which is NEON.

There are two build items,

1) hns3_rxtx_vec_sve.c
2) rest of the library

There is already runtime checks to select Rx/Tx functions, so it is safe to
build (1) as long as compiler supports. If the platform doesn't support SVE, the
SVE path won't be selected during runtime.

For (2), it should be build to support NEON only, if it is compiled to support
SVE, it won't run on the platform that only supports NEON.

So, in below, if '__ARM_FEATURE_SVE' is supported, all driver is build with SVE
support, won't this cause a problem on the NEON platform?

In that case, the rest of DPDK is being build with SVE so having one driver
neon-only doesn't really make sense.

Overall, the patch looks to mirror what we do for AVX2/AVX512 support in
the Intel drivers, so looks ok to me.

I agree there is no point to make driver specific change if whole DPDK build
with SVE, and that seems controlled by user as Honnappa clarified.
So I will proceed with patch, thanks.