Skip to contentSkip to conversation

packed ring loopback large pkts test can't fwd packets correctly after vhost relaunching

dpdk-dev [email protected] 1 participant 1 message Aug 9, 2021

lore
Share & tools
lore

[email protected]

author Reviewed-by Chenbo Xia
#0 lore raw

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

Bug ID: 782
Summary: [dpdk-20.11] packed ring loopback large pkts test
can't fwd packets correctly after vhost relaunching
Product: DPDK
Version: 21.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-20.11.0 b1d36cf828771e28eb0130b59dcf606c2a0bc94d Other software versions: N/A.
OS: Ubuntu 20.04.2 LTS/Linux 5.4.0-42-generic
Compiler: gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) Hardware platform: Intel(R) Xeon(R) Platinum 8280M CPU @ 2.70GHz. NIC hardware: FVL-40g.
NIC firmware & driver:
driver: i40e
version: 5.11.16-051116-generic
firmware-version: 8.30 0x8000a4ae 1.2926.0

Test Setup
Steps to reproduce
List the steps to reproduce the issue.

1. launch vhost:
./x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 32-33 -n 4 --no-pci --vdev
'eth_vhost0,iface=vhost-net0,queues=1,client=1' -- -i --nb-cores=1 --rxq=1 --txq=1 --txd=1024 --rxd=1024
set fwd csum
start

2. launch virtio-user and send large pkts, check loopback performance:
x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 30,31 -n 4
--file-prefix=testpmd0 --no-pci --vdev=net_virtio_user0,mac=00:11:22:33:44:10,path=./vhost-net0,queues=1,mrg_rxbuf=1,in_order=0,packed_vq=1,server=1 -- -i --nb-cores=1 --rxq=1 --txq=1 --txd=1024 --rxd=1024
set fwd csum
set txpkts 2000,2000,2000,2000
start tx_first 32
show port stats all #get 0.7mpps

testpmd> show port stats all

######################## NIC statistics for port 0 ########################
RX-packets: 7131896 RX-missed: 0 RX-bytes: 57055200000
RX-errors: 0
RX-nombuf: 0
TX-packets: 7132472 TX-errors: 0 TX-bytes: 57059776000

Throughput (since last show)

  Rx-pps:       772402          Rx-bps:  49434132192
  Tx-pps:       772402          Tx-bps:  49433768720

############################################################################

3.quit vhost and relaunch vhost with same cmd:
./x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 32-33 -n 4 --no-pci --vdev
'eth_vhost0,iface=vhost-net0,queues=1,client=1' -- -i --nb-cores=1 --rxq=1 --txq=1 --txd=1024 --rxd=1024
set fwd csum
start

4. stop virtio-user and re-send large pkts, check loopback performance:
stop
set fwd csum
set txpkts 2000,2000,2000,2000
start tx_first 32
show port stats all #get 1.9 mpps, suspect pkts payload not correct
######################## NIC statistics for port 0 ########################
RX-packets: 25519650 RX-missed: 0 RX-bytes: 79521868024
RX-errors: 110
RX-nombuf: 0
TX-packets: 25520795 TX-errors: 0 TX-bytes: 79531070864

Throughput (since last show)

  Rx-pps:      1891019          Rx-bps:  30921946440
  Tx-pps:      1891019          Tx-bps:  30921946440

############################################################################

Expected Result
Explain what is the expected result in text or as an example output:

After vhost relaunch, loopback throughput is same with before vhost relaunch. Regression
Is this issue a regression: (Y)

Version the regression was introduced: Specify git id if known.

Bad commit:
commit 9af79db20f4cf75
Author: Maxime Coquelin <[email protected]>
Date: Tue Jan 26 11:16:32 2021 +0100

net/virtio: make server mode blocking

This patch makes the Vhost-user backend server mode blocking at init, waiting for the client connection.

The goal is to make the driver more reliable, as without waiting for client connection, the Virtio driver has to assume the Vhost-user backend will support all the features it has advertized, which could lead to undefined behaviour.

For example, without this patch, if the user enables packed ring Virtio feature but the backend does not support it, the ring initialized by the driver will not be compatible with the backend.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.