Trying to isolate the commands used in the failing test (works in a not too small Oracular VM):
0. Prep install and config
apt install openvswitch-switch-dpdk dpdk-dev
echo "NR_2M_PAGES=784" >> /etc/dpdk/dpdk.conf
systemctl restart dpdk
update-alternatives --set ovs-vswitchd /usr/lib/openvswitch-switch-dpdk/ovs-vswitchd-dpdk
ovs-vsctl --no-wait init
ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true
ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-extra="--log-level=pmd.*:error --no-pci"
1. start OVS with DPDK support (this is the point where you'd restart new test iterations)
systemctl stop openvswitch-switch ovs-vswitchd
rm /var/log/openvswitch/ovs-vswitchd.log
systemctl start openvswitch-switch ovs-vswitchd
ovs-vsctl show
2. create an internal DPDK bridge with a vhostuserclient port with defined MTU
ovs-vsctl add-br br10 -- set bridge br10 datapath_type=netdev
OVS_RUNDIR="/tmpdir/_debian/tests/system-dpdk-testsuite.dir/020"
rm -rf $OVS_RUNDIR
mkdir -p $OVS_RUNDIR
ovs-vsctl add-port br10 dpdkvhostuserclient0 -- set Interface dpdkvhostuserclient0 type=dpdkvhostuserclient options:vhost-server-path=$OVS_RUNDIR/dpdkvhostclient0
ovs-vsctl show
3. connect a vhostuserclient server
# Do this in a shell of its own, it will stay up
dpdk-testpmd --in-memory --socket-mem=512 --single-file-segments --no-pci --vdev="net_virtio_user,path=$OVS_RUNDIR/dpdkvhostclient0,server=1 --vdev=net_tap0,iface=tap0 -- -a --stats-period 2 --nb-cores 2 --rxq 2 --txq 2
4. check if it is truly ready
ovs-vsctl show
grep "virtio is now ready for processing" /var/log/openvswitch/ovs-vswitchd.log
# should have a happy dpdkvhostuserclient0
ovs-vsctl get Interface dpdkvhostuserclient0 link_state
# should say "up"
5. set happy MTU
ovs-vsctl set Interface dpdkvhostuserclient0 mtu_request=9702
ovs-vsctl get Interface dpdkvhostuserclient0 mtu
# should deliver 9702
6. set the bigger MTU
ovs-vsctl set Interface dpdkvhostuserclient0 mtu_request=9711
# the ovs-vswitchd.log will say (expected)
dpdkvhostuserclient0: unsupported MTU 9711
failed to set MTU for network device dpdkvhostuserclient0: Invalid argument
ovs-vsctl get Interface dpdkvhostuserclient0 mtu
# will still deliver 9702
7. cleanup the port
ovs-vsctl del-port br10 dpdkvhostuserclient0
# Should work without bad RC, log in ovs-vswitchd.log will say:
bridge|INFO|bridge br10: deleted interface dpdkvhostuserclient0 on port 1
dpif_netdev|INFO|PMD thread on numa_id: 0, core id: 1 destroyed.
dpdk(pmd-c01/id:8)|INFO|PMD thread released DPDK lcore 1.
dpdk|INFO|VHOST_CONFIG: (/tmpdir/_debian/tests/system-dpdk-testsuite.dir/020/dpdkvhostclient0) free connfd 50
netdev_dpdk|INFO|vHost Device '/tmpdir/_debian/tests/system-dpdk-testsuite.dir/020/dpdkvhostclient0' not found
ovs-vsctl del-br br10
ovs-vsctl show
# should show an empty switch
^^ Here I expected the issue with the new code (OVS + DPDK being new).
But sadly I have proven that the "not found" on the path was a red herring as well.
It comes up in the good path as well.
The good case just does not push the log output to the test-output.
Hence it seemed to be an issue "only in the bad case" but that was a fluke.
Trying to isolate the commands used in the failing test (works in a not too small Oracular VM):
0. Prep install and config switch- dpdk dpdk-dev alternatives --set ovs-vswitchd /usr/lib/ openvswitch- switch- dpdk/ovs- vswitchd- dpdk dpdk-init= true dpdk-extra= "--log- level=pmd. *:error --no-pci" openvswitch/ ovs-vswitchd. log type=netdev "/tmpdir/ _debian/ tests/system- dpdk-testsuite. dir/020" ient0 -- set Interface dpdkvhostusercl ient0 type=dpdkvhostu serclient options: vhost-server- path=$OVS_ RUNDIR/ dpdkvhostclient 0 file-segments --no-pci --vdev= "net_virtio_ user,path= $OVS_RUNDIR/ dpdkvhostclient 0,server= 1 --vdev= net_tap0, iface=tap0 -- -a --stats-period 2 --nb-cores 2 --rxq 2 --txq 2 openvswitch/ ovs-vswitchd. log ient0 ient0 link_state ient0 mtu_request=9702 ient0 mtu ient0 mtu_request=9711 rclient0: unsupported MTU 9711 ient0: Invalid argument ient0 mtu ient0 INFO|bridge br10: deleted interface dpdkvhostusercl ient0 on port 1 netdev| INFO|PMD thread on numa_id: 0, core id: 1 destroyed. pmd-c01/ id:8)|INFO| PMD thread released DPDK lcore 1. INFO|VHOST_ CONFIG: (/tmpdir/ _debian/ tests/system- dpdk-testsuite. dir/020/ dpdkvhostclient 0) free connfd 50 dpdk|INFO| vHost Device '/tmpdir/ _debian/ tests/system- dpdk-testsuite. dir/020/ dpdkvhostclient 0' not found
apt install openvswitch-
echo "NR_2M_PAGES=784" >> /etc/dpdk/dpdk.conf
systemctl restart dpdk
update-
ovs-vsctl --no-wait init
ovs-vsctl --no-wait set Open_vSwitch . other_config:
ovs-vsctl --no-wait set Open_vSwitch . other_config:
1. start OVS with DPDK support (this is the point where you'd restart new test iterations)
systemctl stop openvswitch-switch ovs-vswitchd
rm /var/log/
systemctl start openvswitch-switch ovs-vswitchd
ovs-vsctl show
2. create an internal DPDK bridge with a vhostuserclient port with defined MTU
ovs-vsctl add-br br10 -- set bridge br10 datapath_
OVS_RUNDIR=
rm -rf $OVS_RUNDIR
mkdir -p $OVS_RUNDIR
ovs-vsctl add-port br10 dpdkvhostusercl
ovs-vsctl show
3. connect a vhostuserclient server
# Do this in a shell of its own, it will stay up
dpdk-testpmd --in-memory --socket-mem=512 --single-
4. check if it is truly ready
ovs-vsctl show
grep "virtio is now ready for processing" /var/log/
# should have a happy dpdkvhostusercl
ovs-vsctl get Interface dpdkvhostusercl
# should say "up"
5. set happy MTU
ovs-vsctl set Interface dpdkvhostusercl
ovs-vsctl get Interface dpdkvhostusercl
# should deliver 9702
6. set the bigger MTU
ovs-vsctl set Interface dpdkvhostusercl
# the ovs-vswitchd.log will say (expected)
dpdkvhostuse
failed to set MTU for network device dpdkvhostusercl
ovs-vsctl get Interface dpdkvhostusercl
# will still deliver 9702
7. cleanup the port
ovs-vsctl del-port br10 dpdkvhostusercl
# Should work without bad RC, log in ovs-vswitchd.log will say:
bridge|
dpif_
dpdk(
dpdk|
netdev_
ovs-vsctl del-br br10
ovs-vsctl show
# should show an empty switch
^^ Here I expected the issue with the new code (OVS + DPDK being new).
But sadly I have proven that the "not found" on the path was a red herring as well.
It comes up in the good path as well.
The good case just does not push the log output to the test-output.
Hence it seemed to be an issue "only in the bad case" but that was a fluke.