On 8/24/23 17:22, Aaron Conole wrote: > David Marchand <david.march...@redhat.com> writes: > >> On Wed, Aug 23, 2023 at 5:35 PM David Marchand >> <david.march...@redhat.com> wrote: >>> >>> Integrate system-traffic.at tests as part of check-dpdk. >> >> CI (thinking of Intel robot) other than GHA might not be too happy >> about this change. >> It is hard to tell what fails in the report I received. >> >> A safer approach is probably to define a new check-XXX target instead >> of expanding check-dpdk. > > I'm not sure - at least for Intel, we can ask them to investigate. > > I noticed that we didn't get any new results from intel after this > patch, so I wonder if this change broke something. > > I also noticed that without the conntrack tests (7/7) this passed, but > with them, we got a failure report. Is it possible that the tests are > taking too long (in which case, we need to investigate a way of > optimizing this).
I believe, all the tests failed because of this: > 2023-08-23T22:23:10.040Z|00088|dpdk|ERR|tap_dev_configure(): net_taptap1: > number of rx queues 2 must be equal to number of tx queues 3 > 2023-08-23T22:23:10.040Z|00089|dpdk|ERR|Port0 dev_configure = -1 > 2023-08-23T22:23:10.040Z|00090|netdev_dpdk|WARN|Interface ovs-tap1 eth_dev > setup error Operation not permitted > 2023-08-23T22:23:10.040Z|00091|netdev_dpdk|ERR|Interface ovs-tap1(rxq:2 txq:3 > lsc interrupt mode:false) configure error: Operation not permitted > 2023-08-23T22:23:10.040Z|00092|netdev_dpdk|INFO|ovs-tap1: rx-steering: > default rss > 2023-08-23T22:23:10.040Z|00093|dpif_netdev|ERR|Failed to set interface > ovs-tap1 new configuration > 2023-08-23T22:23:10.040Z|00094|dpif_netdev|INFO|Performing pmd to rx queue > assignment using cycles algorithm. > 2023-08-23T22:23:10.040Z|00095|dpif_netdev|INFO|Core 21 on numa node 0 > assigned port 'dpdkvhostuser0' rx queue 0 (measured processing cycles 0). > 2023-08-23T22:23:10.040Z|00096|dpif|WARN|netdev at ovs-netdev: failed to add > ovs-tap1 as port: Invalid argument > 2023-08-23T22:23:10.040Z|00097|bridge|WARN|could not add network device > ovs-tap1 to ofproto (Invalid argument) And failing tests typically take much longer, because we wait for some traffic or some flows that never appear. Configuration for net/tap DPDK ports should be managed more carefully in the tests. We will likely have to use dummy NUMA even. The Lab seems to work fine. Error reporting could be better, but it's enough to identify the issue in this case. We should also keep in mind that these tests should pass in the debian autopkgtest environment: https://patchwork.ozlabs.org/project/openvswitch/patch/20230627101104.72417-2-frode.nord...@canonical.com/ Even if we don't have this merged, this is what Ubuntu/Debian folks are running internally. Best regards, Ilya Maximets. > >>> >>> DPDK net/tap specific logs are added to the log exclusions. >>> >>> 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. >>> >>> Signed-off-by: David Marchand <david.march...@redhat.com> > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
