vhost_virtio_user_interrupt_with_power_monitor/perf_wake_up_split_ring_vhost_user_core_with_l3fwd_power_sample：virtio-user can't receive packet

https://bugs.dpdk.org/show_bug.cgi?id=1338

            Bug ID: 1338
           Summary: [dpdk-22.11.4]
                    vhost_virtio_user_interrupt_with_power_monitor/perf_wa
                    ke_up_split_ring_vhost_user_core_with_l3fwd_power_samp
                    le：virtio-user can't receive packet
           Product: DPDK
           Version: 22.11
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: vhost/virtio
          Assignee: [email protected]
          Reporter: [email protected]

Target Milestone: ---

[Environment]
DPDK version: dpdk 22.11.4-rc3: 4307659a90
OS: Ubuntu 22.04.3 LTS/5.15.0-87-generic
Compiler: gcc version 11.4.0
Hardware platform: SPR(Intel(R) Xeon(R) Platinum 8490H) NIC hardware: Ethernet Controller E810-C for QSFP 1592 NIC firmware: 4.40 0x8001c2f1 1.3492.0
NIC kdriver: ice-1.13.3_dirty

[Test Setup]
Steps to reproduce
1. ssh root@dpdk-yingya-spr2
Compile DPDK::
meson -Dexamples=l3fwd-power x86_64-native-linuxapp-gcc ninja -C x86_64-native-linuxapp-gcc

2.bind NIC port to vfio-pci,
./usertools/dpdk-devbind.py -b vfio-pci 45:00.0

3. Launch virtio-user with server mode::
./x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 3-4 -n 8 -a 0000:45:00.0 --vdev net_virtio_user0,path=./vhost-net,server=1,queues=1 -- -i --rxq=1 --txq=1

4. Launch vhost with l3fwd-power::
./x86_64-native-linuxapp-gcc/examples/dpdk-l3fwd-power -l 5-6 -n 8
--file-prefix=l3fwd-pwd_216146_20231228175051 --no-pci --vdev
net_vhost0,iface=./vhost-net,queues=1,client=1 --log-level='user1,7' -- -p 1
--config='(0,0,5)' --parse-ptype --pmd-mgmt=monitor

5. Start virtio-user::
testpmd>start

6. Sent imix packets from TG

[Show the output from the previous commands]
pktgen: ixia packet generator: run traffic 5s to warm up ...
pktgen: begin traffic ......
tester: scp -v ixiaConfig.tcl root@dpdk-yingya-spr2:~/
pktgen: source ixiaConfig.tcl
pktgen: ixStopTransmit portList
pktgen: traffic completed.
pktgen: begin traffic ......
tester: scp -v ixiaConfig.tcl root@dpdk-yingya-spr2:~/
pktgen: source ixiaConfig.tcl
pktgen: begin get port statistic ...
pktgen: stat getRate statAllStats 1 3 4
pktgen: stat cget -framesReceived
pktgen: stat cget -bitsReceived
pktgen: stat cget -oversize
pktgen: throughput: pps_rx 0.000000, bps_rx 0.000000

[Expected Result]
check packets can fwd back with correct payload.

Regression
Is this issue a regression: (Y/N) Y
test on SPR only
The commit a07736eb68 will build failed
8c291d8778 tested failed (vhost: fix checking virtqueue access in stats API) a07736eb68 build failed (vhost: fix missing lock protection in power monitor API) (/lib/vhost/vhost.c:2171:13: error: unused variable ‘ret’ [-Werror=unused-variable])
adae353b36 tested passed (vhost: fix check on virtqueue access in in-flight getter)

bad commit 8c291d87783d2e22e6234cddc23bee27d0f14dae (HEAD -> 22.11)

Author: Maxime Coquelin <[email protected]>
Date:   Fri Oct 20 10:48:04 2023 +0200

vhost: fix checking virtqueue access in stats API

[ upstream commit a004501a147889d608008ab6f18355e9b0ceff65 ]

Acquiring the access lock is not enough to ensure virtqueue's metadata such as vring pointers are valid.

The access status must also be checked.

You are receiving this mail because:
You are the assignee for the bug.

https://bugs.dpdk.org/show_bug.cgi?id=1338

[email protected] changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from [email protected] ---
fix commit dc9c799c7d vhost: fix missing spinlock unlock
Two regressions were introduced when backporting below patch:
b4c4e5675c85 ("vhost: fix missing lock protection in power monitor API")

First, rte_vhost_get_monitor_addr did not release the lock in the success case. Then, rte_rwlock_read_lock() was converted to rte_spinlock_trylock() instead of rte_spinlock_lock().

This patch addresses both of these issues.

You are receiving this mail because:
You are the assignee for the bug.