On Fri, Aug 25, 2023 at 12:57 PM Eelco Chaudron <echau...@redhat.com> wrote: > > > > +m4_define([OVS_DPDK_STOP_VSWITCHD], > > + [OVS_VSWITCHD_STOP([dnl > > +$1";/does not exist. The Open vSwitch kernel module is probably not > > loaded./d > > +/does not support MTU configuration,/d > > +/EAL: No \(available\|free\) .*hugepages reported/d > > +/Failed to enable flow control/d > > +/Rx checksum offload is not supported on/d > > +/TELEMETRY: No legacy callbacks, legacy socket not created/d"]) > > On my VMs (with all patches applied) all the existing dpdk tests and new ones > are failing due to the following error messages:
As you mention, the issue predates this current patch and it points at a different problem than the logs matching. > > +2023-08-25T10:09:42.252Z|00016|dpdk|ERR|eth_virtio_pci_init(): Failed to > init PCI device > +2023-08-25T10:09:42.252Z|00017|dpdk|ERR|EAL: Requested device 0000:00:05.0 > cannot be used > +2023-08-25T10:09:42Z|00016|dpdk|ERR|eth_virtio_pci_init(): Failed to init > PCI device > +2023-08-25T10:09:42Z|00017|dpdk|ERR|EAL: Requested device 0000:00:05.0 > cannot be used > > Maybe we could exclude them here (this is what I did) or add some --no-pci > option (and make sure the ones that do need them have it). > > @@ -93,6 +93,8 @@ $1";/does not exist. The Open vSwitch kernel module is > probably not loaded./d > /eth_dev_tap_create(): .*: failed to create multiq qdisc./d > /eth_dev_tap_create(): Disabling rte flow support: No such file or > directory/d > /tap_mp_req_on_rxtx(): Failed to send start req to secondary/d > +/eth_virtio_pci_init(): Failed to init PCI device/d > +c > /does not exist. The Open vSwitch kernel module is probably not loaded./d"]) > ]) > Those warnings are due to the fact that OVS lets DPDK try to grab all devices by default. And here, we are affected by a port that you don't seem to care about. Besides, about log matching, in the context of the phy port tests, we do want to catch errors like "EAL: Requested device .* cannot be used". You could also imagine someone passing the PCI device of a virtio-net for those tests to run so I would not filter the virtio errors. So I don't think we should ignore those specific logs in the common macro. Passing --no-pci in the tests that wants to probe one pci device is not doable. What I think instead is that having DPDK probes all devices by default is not desirable, though it has been working like this since OVS integrated DPDK. I have a patch in store for a long time, I just never found an explicit need for it and it had some drawback in one usecase (multiple ports for a single pci device), maybe I could send a rfc. -- David Marchand _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
