On 8/30/23 10:28, David Marchand wrote: > Integrate system-traffic.at tests as part of check-dpdk. > > Some tests that can't work with the userspace datapath are skipped by > overriding some OVS_CHECK_* macros. > > ADD_VETH is implemented with a tap interface in the kernel, directly > polled by OVS with the net/tap DPDK driver. > ADD_VETH_IGNORE_LOGS is provided to filter warning logs that may be > emitted (like for example, lack of DPDK multiprocess feature which OVS > does not care about). > > This driver expects an equal number of rxq and txq. > On the other hand, OVS spawns one PMD thread per numa node, and OVS > reserves one txq for non PMD thread usage. > This means that a net/tap port n_rxq must be set to numa_count + 1. > > Signed-off-by: David Marchand <david.march...@redhat.com> > --- > Changes since v3: > - reverted --dummy-numa and opted for configuring a number of rxqs > relevant to the number of NUMA sockets, > > Changes since v2: > - added ADD_VETH_IGNORE_LOGS and moved ignored error logs to > OVS_TRAFFIC_VSWITCHD_STOP, > - added --no-pci to DPDK options to avoid failing the tests when > running in a vm with a virtio-net device, > - faked a mono numa/mono core so that OVS requests at max 2 txqs on > the net/tap port, > > --- > tests/system-dpdk-macros.at | 95 ++++++++++++++++++++++++++++++++++ > tests/system-dpdk-testsuite.at | 2 + > tests/system-dpdk.at | 7 +-- > 3 files changed, 99 insertions(+), 5 deletions(-) > > diff --git a/tests/system-dpdk-macros.at b/tests/system-dpdk-macros.at > index f29b3c283f..ce8e98f475 100644 > --- a/tests/system-dpdk-macros.at > +++ b/tests/system-dpdk-macros.at > @@ -124,3 +124,98 @@ m4_define([OVS_DPDK_STOP_TESTPMD], > [AT_CHECK([kill `cat testpmd.pid`]) > OVS_WAIT([kill -0 `cat testpmd.pid`], [kill -9 `cat testpmd.pid`]) > ]) > + > + > +# OVS_TRAFFIC_VSWITCHD_START([vsctl-args], [vsctl-output], [dbinit-aux-args]) > +# > +# Creates a database and starts ovsdb-server, starts ovs-vswitchd > +# connected to that database, calls ovs-vsctl to create a bridge named > +# br0 with predictable settings, passing 'vsctl-args' as additional > +# commands to ovs-vsctl. If 'vsctl-args' causes ovs-vsctl to provide > +# output (e.g. because it includes "create" commands) then 'vsctl-output' > +# specifies the expected output after filtering through uuidfilt. > +# 'dbinit-aux-args' are passed as additional commands to 'ovs-vsctl init' > +# before starting ovs-vswitchd. > +m4_define([OVS_TRAFFIC_VSWITCHD_START], > + [ > + OVS_DPDK_PRE_CHECK() > + OVS_WAIT_WHILE([ip link show ovs-netdev]) > + dnl For functional tests, no need for DPDK PCI probing. > + OVS_DPDK_START([--no-pci], [--disable-system], [$3]) > + dnl Add bridges, ports, etc. > + OVS_WAIT_WHILE([ip link show br0]) > + AT_CHECK([ovs-vsctl -- _ADD_BR([br0]) -- $1 m4_if([$2], [], [], [| > uuidfilt])], [0], [$2]) > +]) > + > + > +# OVS_TRAFFIC_VSWITCHD_STOP([ALLOWLIST], [extra_cmds]) > +# > +# Gracefully stops ovs-vswitchd and ovsdb-server, checking their log files > +# for messages with severity WARN or higher and signaling an error if any > +# is present. The optional ALLOWLIST may contain shell-quoted "sed" > +# commands to delete any warnings that are actually expected, e.g.: > +# > +# OVS_TRAFFIC_VSWITCHD_STOP(["/expected error/d"]) > +# > +# 'extra_cmds' are shell commands to be executed after OVS_VSWITCHD_STOP() is > +# invoked. They can be used to perform additional cleanups such as name space > +# removal. > +m4_define([OVS_TRAFFIC_VSWITCHD_STOP], > + [OVS_DPDK_STOP_VSWITCHD([$1";"ADD_VETH_IGNORE_LOGS";dnl > +/does not exist. The Open vSwitch kernel module is probably not loaded./d"]) > + AT_CHECK([:; $2]) > +]) > + > + > +m4_define([OVS_CHECK_8021AD], > + [AT_SKIP_IF([:])]) > + > + > +m4_define([OVS_CHECK_TC_QDISC], > + [AT_SKIP_IF([:])]) > + > + > +m4_define([OVS_CHECK_TCPDUMP], > + [AT_SKIP_IF([:])]) > + > + > +# Fake a veth by creating a tap on kernel side and plug it in OVS using the > +# net/tap DPDK driver.
Why do we need to fake a veth? It looks strange to me and also error prone as taps do not behave like veths in some cases. Can we just have a veth and open it with af_packet ports like all other testsuites do? Best regards, Ilya Maximets. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
