On Thu, Aug 24, 2023 at 7:52 PM Ilya Maximets <i.maxim...@ovn.org> wrote: > > 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
Yes, it seems to be the reason though I did not understand why those rxq/txq count were used. > > 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. Oh that's the catch, numa... I reproduced in a vm and I have something that seems to work, testing a bit more. > > 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. Ok. For now, I don't see what could be blocking, do you have any specific problem in mind? -- David Marchand _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
