|WARNING| vhost: make cryptodev support optional
dpdklab at iol.unh.edu
dpdklab at iol.unh.edu
Wed Oct 14 21:38:08 CEST 2026
Test-Label: ai-code-review
Test-Status: WARNING
https://dpdk.org/patch/171345
_AI Code Review_
=== Patch Review: series.patch (via Claude) ===
Review date: 2026-10-14
# DPDK Patch Review
## ERRORS
None identified.
## WARNINGS
**1. Missing release notes update**
This patch makes cryptodev support optional in vhost, which is a significant behavioral change that affects build configuration and feature availability. The release notes should be updated to document:
- That vhost cryptodev support is now conditional on RTE_LIB_CRYPTODEV
- How users can enable/disable this feature
- Any implications for applications using vhost crypto
The change affects users who rely on vhost crypto functionality, and those building DPDK without cryptodev.
**Suggested fix:** Add a section to `doc/guides/rel_notes/release_26_11.rst` (or current release file) documenting this change.
**2. Missing cryptodev driver dependency**
The original code had `deps += ['cryptodev', 'hash']` unconditionally. The patch moves this inside the conditional block but only adds back `'cryptodev'` and `'hash'`. However, the vhost library was originally depending on cryptodev, and now it's optional.
The conditional check uses `dpdk_conf.has('RTE_LIB_CRYPTODEV')` which verifies the library is built, but there's no corresponding update to `deps` that would ensure proper linking when cryptodev is disabled.
**Verification needed:** Confirm that when `RTE_LIB_CRYPTODEV` is not defined:
- The vhost library still builds correctly
- No undefined symbols are introduced
- The conditional properly excludes vhost_crypto.c from compilation
The code appears correct, but this is a non-trivial dependency change that warrants careful build testing across configurations.
## INFO
**1. Build system dependency pattern**
The pattern used here (`dpdk_conf.has('RTE_LIB_CRYPTODEV')`) for conditional compilation is consistent with DPDK's approach for optional features. This is the correct way to make a library dependency optional in meson.
**2. CVE mitigation approach**
The commit message mentions CVEs as motivation. Making the feature optional is a reasonable approach to allow security-conscious deployments to disable functionality they don't need, following the principle of reducing attack surface.
Review-Result: WARNING
More information about the test-report
mailing list