memif: ring semantics differ from VPP
https://bugs.dpdk.org/show_bug.cgi?id=2015
Bug ID: 2015
Summary: memif: ring semantics differ from VPP
Product: DPDK
Version: 26.11
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: minor
Priority: Normal
Component: ethdev
Assignee: [email protected]
Reporter: [email protected]Target Milestone: ---
Found when doing AI assisted analysis and comparison of DPDK memif with VPP.
The two memif implementations disagree by one about what the hello limit fields mean.
DPDK sends h->max_region = ETH_MEMIF_MAX_REGION_NUM - 1, treating the field as an inclusive maximum index, and checks received indices with
Quoted 1 line
= against
ETH_MEMIF_MAX_REGION_NUM.
VPP sends h->max_region = MEMIF_MAX_REGION (256) and checks received indices with > rather than >=, so it accepts index 256 and therefore 257 regions. The same > form is used for its ring index checks.
Nothing is memory-unsafe on either side today, because both clamp what they actually use, and VPP's regions are vectors. But the accepted range and the advertised range do not agree, and the two stacks do not agree with each other.
There is no memif specification outside VPP's tree, so this is the kind of thing that only gets settled by writing it down. It should be pinned in whatever wire contract comes out of the current memif hardening work, and DPDK's side adjusted to match once the meaning is agreed.
Raised here so it is on the record and does not get fixed unilaterally in one stack in a way that breaks the other.
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.