dpdk (22.11.1-2)
[PTS] [DDPO]
COMMITS: VCS has seen 3 commits since the debian/22.11.1-2 tag
- Git: https://salsa.debian.org/debian/dpdk.git -b unstable
-
- Branch: unstable
- Path: debian/changelog
- Repo size: 160329728
- Browser: https://salsa.debian.org/debian/dpdk
- Last scan: 2023-03-23 22:27:29+00
- Next scan: 2023-03-31 18:29:00+00
- Merge requests: 1
- CI pipeline status: failed
- Debian changelog in Git:
dpdk (22.11.1-2) unstable; urgency=medium
* d/watch: restrict to 22.11 LTS
* Upload to unstable
-- Luca Boccassi <bluca@debian.org> Sat, 17 Dec 2022 13:59:11 +0000
- This branch is 3 commits ahead of tag debian/22.11.1-2
- Git log:
commit 6ef90cd28bd50fc36622ab4ea37d45293d66f1a0
Author: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Date: Fri Jan 27 11:25:08 2023 +0100
d/control, d/dpdk.init: stop using lsb-base functions
The sysV compatibility is not widely in use and we can see the lintian error
E: dpdk: depends-on-obsolete-package Depends: lsb-base (>= 3.2-14)
as a chance to simplify the init script.
99+% of the people will use the .service anyway, those few (if any) using
the sysV script do not really degrade a lot by changing the custom log_
functions of lsb_base to normal echo calls.
That change allows to completely drop this dependency.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
commit a53d16c16d594df26488185e225669708b49cd4b
Author: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Date: Thu Jan 26 14:42:29 2023 +0100
d/rules: avoid path length issues in build time test
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
commit 56ae5d3ddd728a7db5ec34ab0596d743f988f925
Author: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Date: Tue Jan 24 10:14:56 2023 +0100
d/t/test-fastsuite: test env before breaking tests for known issues
As we had it in the past with the full testsuite on x86 (missing sse4.2)
we now also have some arm64 systems only do armv8.0 without crc32 (non
mandatory feature).
That triggers issues like
HASH: Unsupported CRC32 algorithm requested using CRC32_SW
ERROR: This system does not support "CRC32".
Please check that RTE_MACHINE is set correctly.
EAL: FATAL: unsupported cpu type.
EAL: unsupported cpu type.
63/63 DPDK:fast-tests / telemetry_all FAIL
1.22s (exit status 255 or signal 127 SIGinvalid)
This breaks all the tests and flags it as regression which is wrong.
Background:
config/meson.build detects that it is on arm and then processes
config/arm/meson.build which checks for __ARM_FEATURE_CRC32 (a required flag
anyway) and then stores that it considered this to be present in
RTE_COMPILE_TIME_CPUFLAGS.
Note: The machine type "default" is the least optimized most common
denominator by DPDK. And on arm that is mapped to generic. In Focal that
was "['default', ['-march=armv8-a+crc']]," in Jammy the core split arch and
features but still is:
'generic': {
'march': 'armv8-a',
'march_features': ['crc'],
'compiler_options': ['-moutline-atomics']
},
So requiring CRC32 is not new and a minimum as defined by upstream.
Then at runtime (or test time for us) on load of the binary it checks if the
environment is having all features that it expects which is great - much better
than a late crazy crash.
So it checks for crc32 which not all our test environments seem to have.
Just as with SSE4.2 which is a simular situation on x86 we should be adding
a check to the tests to reduce flakyness of test results.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
