You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These 2 CPU features (RDSEED and RDRAND) cause the spdk container not to work in some Intel Xeon CPUs (3-4 years old):
nvmeof_1 | ERROR: This system does not support "RDSEED".
nvmeof_1 | Please check that RTE_MACHINE is set correctly.
nvmeof_1 | EAL: FATAL: unsupported cpu type.
nvmeof_1 | EAL: unsupported cpu type.
nvmeof_1 | [2023-06-23 23:12:55.662422] init.c: 602:spdk_env_init: *ERROR*: Failed to initialize DPDK
nvmeof_1 | [2023-06-23 23:12:55.662447] app.c: 351:app_setup_env: *ERROR*: Unable to initialize SPDK env
While there's a DPDK proposal to detect this support at runtime, that's unlikely to be merged. Given we aren't strictly relying on those features for FIPS-140 compliant encryption, we could simply disable these by default.
Workaround
Build the spdk and nvmeof container images locally in the environment without RDSEED support:
make build SVC="spdk nvmeof"
Long-term solution
Either:
Generate 2 container flavors: with and without RDSEED.
Disable RDSEED for all builds, since nvmeof doesn't seem to rely on that.
These 2 CPU features (RDSEED and RDRAND) cause the
spdk
container not to work in some Intel Xeon CPUs (3-4 years old):While there's a DPDK proposal to detect this support at runtime, that's unlikely to be merged. Given we aren't strictly relying on those features for FIPS-140 compliant encryption, we could simply disable these by default.
Workaround
Build the spdk and nvmeof container images locally in the environment without
RDSEED
support:Long-term solution
Either:
nvmeof
doesn't seem to rely on that.The text was updated successfully, but these errors were encountered: