DPDK usage discussions
 help / color / mirror / Atom feed
From: =?gb18030?B?oaShpKGkoaShpKGk?= <1104121601@qq.com>
To: =?gb18030?B?dXNlcnM=?= <users@dpdk.org>
Subject: Virtio PMD Issue: Packed Queue desc_event_flags Causing Testpmd Crash
Date: Fri, 10 Oct 2025 15:34:31 +0800	[thread overview]
Message-ID: <tencent_02602621A0D85AC18D386F5C8BE8BD0D2906@qq.com> (raw)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset="gb18030", Size: 4974 bytes --]

Dear DPDK Community/Maintainers.


I am writing to consult about a technical issue with the Virtio network driver (located in&nbsp;driver/net/virtio). During our testing of the&nbsp;packed queue&nbsp;feature with&nbsp;desc_event_flags&nbsp;enabled, Testpmd consistently crashes after running for a short period. Below is a detailed description of the scenario, observation, root cause analysis, and a proposed fix¡ªwe hope to get clarification on whether this is a usage error or a potential driver issue.

1. Scenario

Test Environment: Running Testpmd with the Virtio PMD (librte_pmd_virtio.so).

Test Focus: Validating the&nbsp;desc_event_flags&nbsp;functionality of Virtio&nbsp;packed queue&nbsp;mode.

2. Observation
After Testpmd runs for several minutes, it crashes unexpectedly. Debugging shows that the content of&nbsp;vq_descx&nbsp;(within&nbsp;struct virtqueue) is being modified unexpectedly¡ªlikely due to address mismatches in the queue memory layout.

3. Command Used to Reproduce
testpmd -c 0xff -n 4 --huge-dir=/mnt/huge_dpdk --socket-mem=1024 --socket-limit=1024 -w 0000:15:00.1 --file-prefix=test3 -d /usr/lib64/librte_pmd_virtio.so \
&nbsp; &nbsp; &nbsp; &nbsp; -- --total-num-mbufs=115200 --rxq=4 --txq=4 --forward-mode=txonly --nb-cores=4 --stats-period 1 --burst=512 --rxd=512 --txd=512 --eth-peer=0,10:70:fd:2a:60:39






4. Suspected Root Cause
The Virtio driver uses&nbsp;inconsistent address calculation logic&nbsp;for two critical steps:

When informing the hardware (via the&nbsp;modern_setup_queue&nbsp;interface) of the physical addresses for the&nbsp;driver&nbsp;and&nbsp;device&nbsp;regions of the packed queue.

When calculating the virtual addresses of the&nbsp;driver&nbsp;and&nbsp;device&nbsp;regions for the driver¡¯s own use (via&nbsp;vring_init_packed).
This mismatch leads to the hardware and the driver referencing different memory regions for the&nbsp;device&nbsp;queue, causing unintended overwrites of&nbsp;vq_descx.

5. Detailed Analysis

5.1 Address Calculation in&nbsp;modern_setup_queue&nbsp;(Hardware-facing)
The&nbsp;modern_setup_queue&nbsp;function configures the queue addresses and passes them to the hardware. For packed queues, it calculates&nbsp;desc_addr,&nbsp;avail_addr&nbsp;(driver region), and&nbsp;used_addr&nbsp;(device region) as follows:







Key parameters for our test:

vq_nentries = 0x1000&nbsp;(4096 entries)

sizeof(struct vring_desc) = 16&nbsp;(0x10 in hex)

offsetof(struct vring_avail, ring[vq-&gt;vq_nentries]) = 4 + (0x1000 * 2)&nbsp;(base offset 4 + 2 bytes per ring entry)

Alignment requirement:&nbsp;VIRTIO_PCI_VRING_ALIGN = 4096&nbsp;(0x1000 in hex)
Example calculation (assuming&nbsp;desc_addr = 0x0):

avail_addr = 0x0 + (0x1000 * 0x10) = 0x10000&nbsp;(driver region address passed to hardware)

used_addr = RTE_ALIGN_CEIL(0x10000 + 4 + (0x1000 * 2), 0x1000) = RTE_ALIGN_CEIL(0x12004, 0x1000) = 0x13000&nbsp;(device region address passed to hardware)

5.2 Address Calculation in&nbsp;vring_init_packed&nbsp;(Driver-internal)
The&nbsp;vring_init_packed&nbsp;function calculates the driver-internal virtual addresses for the packed queue¡¯s&nbsp;driver&nbsp;and&nbsp;device&nbsp;regions:





Example calculation (same&nbsp;desc_addr = 0x0,&nbsp;p = 0x0):

vr-&gt;driver = 0x0 + (0x1000 * 0x10) = 0x10000&nbsp;(matches&nbsp;avail_addr&nbsp;from&nbsp;modern_setup_queue)

vr-&gt;device = RTE_ALIGN_CEIL(0x10000 + sizeof(struct vring_packed_desc_event), 0x1000)
Assuming&nbsp;sizeof(struct vring_packed_desc_event) = 4&nbsp;(standard definition), this becomes&nbsp;RTE_ALIGN_CEIL(0x10004, 0x1000) = 0x11000&nbsp;(driver-internal device region address)


5.3 Critical Mismatch

Hardware uses&nbsp;0x13000&nbsp;as the&nbsp;device&nbsp;region address.

Driver uses&nbsp;0x11000&nbsp;as the&nbsp;device&nbsp;region address.

6. Modification Applied to Fix the Issue
We modified&nbsp;modern_setup_queue&nbsp;to use the same address logic as&nbsp;vring_init_packed&nbsp;for packed queues. After this change, Testpmd runs stably without crashes:




7. Reference from Virtio-User/Vhost-User
We noticed that the&nbsp;virtio-user&nbsp;and&nbsp;vhost-user&nbsp;drivers already use the same logic as our modified&nbsp;modern_setup_queue&nbsp;for packed queues. For example, in&nbsp;virtio_user_setup_queue_packed:






8. Question for Clarification
Therefore, for&nbsp;packed queues, why do&nbsp;modern_setup_queue&nbsp;and&nbsp;vring_init_packed&nbsp;use different logic to calculate the&nbsp;device region address?


Is this inconsistency due to&nbsp;incorrect usage on my part, or are there&nbsp;special considerations specific to packed queue mode&nbsp;(e.g., hardware compatibility, protocol requirements)?
We would greatly appreciate your help in clarifying this confusion. Thank you!



Best regards.


[A DPDK user and developer].






¡¤¡¤¡¤¡¤¡¤¡¤
1104121601@qq.com



&nbsp;

[-- Attachment #1.2: Type: text/html, Size: 73996 bytes --]

[-- Attachment #2: E765370F@0248187E.07B7E868.png --]
[-- Type: application/octet-stream, Size: 146645 bytes --]

[-- Attachment #3: D42E8FFF@5C9EFA57.07B7E868.png --]
[-- Type: application/octet-stream, Size: 47772 bytes --]

[-- Attachment #4: 6469B6FC@F640AC44.07B7E868.png --]
[-- Type: application/octet-stream, Size: 165609 bytes --]

[-- Attachment #5: 8D32FC0D@F2147C73.07B7E868.png --]
[-- Type: application/octet-stream, Size: 92459 bytes --]

                 reply	other threads:[~2025-10-10  8:29 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=tencent_02602621A0D85AC18D386F5C8BE8BD0D2906@qq.com \
    --to=1104121601@qq.com \
    --cc=users@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).