* [dpdk-users] qdisc errors on 20.11.1 & Azure
@ 2021-06-28 11:36 Tyler Blair
2021-06-29 17:43 ` Stephen Hemminger
0 siblings, 1 reply; 9+ messages in thread
From: Tyler Blair @ 2021-06-28 11:36 UTC (permalink / raw)
To: users
Hi,
I'm seeing what looks like benign errors from qdisc on testpmd & our DPDK app on Azure. I'm wondering if anyone knows of a way to 'fix' these?
EAL: Detected 8 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: Detected static linkage of DPDK
EAL: Selected IOVA mode 'VA'
EAL: Probing VFIO support...
EAL: VFIO support initialized
EAL: Probe PCI driver: mlx5_pci (15b3:1016) device: 2a8d:00:02.0 (socket 0)
EAL: Probe PCI driver: mlx5_pci (15b3:1016) device: 5ed7:00:02.0 (socket 0)
net_vdev_netvsc: probably using routed NetVSC interface "eth1" (index 3)*
*
*tap_nl_dump_ext_ack(): Cannot delete qdisc with handle of zero**
*
*tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid**
*
*tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid**
*
*tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid**
*
*tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid**
*
*tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid**
*
*tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid**
*
*tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid**
*
*tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid*
[...]
It's not causing any issues that I can see, I'm just wondering if there's a cause for this in the environment that we can fix so we don't have benign errors showing up.
Reproduced by running testpmd with no arguments on Azure:
- OS: Ubuntu 20.04 5.4.0-1048-azure
- DPDK: 20.11.1 (LTS)
- Networking: Azure Accelerated Networking (netvsc)
OS setup is pretty minimal, nothing special other than DPDK is installed.
I don't recall these errors happening while on bare metal - only on Azure.
Thanks!
Regards,
Tyler
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-users] qdisc errors on 20.11.1 & Azure
2021-06-28 11:36 [dpdk-users] qdisc errors on 20.11.1 & Azure Tyler Blair
@ 2021-06-29 17:43 ` Stephen Hemminger
2021-07-05 11:05 ` Tyler Blair
0 siblings, 1 reply; 9+ messages in thread
From: Stephen Hemminger @ 2021-06-29 17:43 UTC (permalink / raw)
To: Tyler Blair; +Cc: users
On Mon, 28 Jun 2021 07:36:12 -0400
"Tyler Blair" <tblair@fastmail.com> wrote:
> Hi,
>
> I'm seeing what looks like benign errors from qdisc on testpmd & our DPDK app on Azure. I'm wondering if anyone knows of a way to 'fix' these?
>
> EAL: Detected 8 lcore(s)
> EAL: Detected 1 NUMA nodes
> EAL: Detected static linkage of DPDK
> EAL: Selected IOVA mode 'VA'
> EAL: Probing VFIO support...
> EAL: VFIO support initialized
> EAL: Probe PCI driver: mlx5_pci (15b3:1016) device: 2a8d:00:02.0 (socket 0)
> EAL: Probe PCI driver: mlx5_pci (15b3:1016) device: 5ed7:00:02.0 (socket 0)
> net_vdev_netvsc: probably using routed NetVSC interface "eth1" (index 3)*
> *
> *tap_nl_dump_ext_ack(): Cannot delete qdisc with handle of zero**
> *
> *tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid**
> *
> *tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid**
> *
> *tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid**
> *
> *tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid**
> *
> *tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid**
> *
> *tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid**
> *
> *tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid**
> *
> *tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid*
> [...]
>
> It's not causing any issues that I can see, I'm just wondering if there's a cause for this in the environment that we can fix so we don't have benign errors showing up.
>
> Reproduced by running testpmd with no arguments on Azure:
>
> - OS: Ubuntu 20.04 5.4.0-1048-azure
> - DPDK: 20.11.1 (LTS)
> - Networking: Azure Accelerated Networking (netvsc)
>
> OS setup is pretty minimal, nothing special other than DPDK is installed.
>
> I don't recall these errors happening while on bare metal - only on Azure.
>
> Thanks!
>
> Regards,
> Tyler
In order to support the tap flow emulation you need to hve the ingress qdisc
and the flower qdisc. Some of the Linux distros have packaged those into
kernels extras type packages.
Or just use netvsc PMD and avoid the problem.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-users] qdisc errors on 20.11.1 & Azure
2021-06-29 17:43 ` Stephen Hemminger
@ 2021-07-05 11:05 ` Tyler Blair
2021-07-05 16:24 ` Stephen Hemminger
0 siblings, 1 reply; 9+ messages in thread
From: Tyler Blair @ 2021-07-05 11:05 UTC (permalink / raw)
To: stephen; +Cc: users
Hi Stephen,
> Some of the Linux distros have packaged those intokernels extras type packages.
> In order to support the tap flow emulation you need to hve the ingress qdisc
> and the flower qdisc. Some of the Linux distros have packaged those into
> kernels extras type packages.
I installed *linux-azure-lts-20.04* and *linux-modules-extra-azure-lts-20.04* to no avail - is this the extras package you are referring to? The extra one maps to *linux-modules-extra-5.4.0-1051-azure*.
> Or just use netvsc PMD and avoid the problem.
This is what we use ( --vdev=net_vdev_netvsc0,iface=eth1 ) so I expect the messages are harmless - just wanted to check if there was a way to hide the message.
Regards,
Tyler
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-users] qdisc errors on 20.11.1 & Azure
2021-07-05 11:05 ` Tyler Blair
@ 2021-07-05 16:24 ` Stephen Hemminger
2021-07-06 14:35 ` Tyler Blair
0 siblings, 1 reply; 9+ messages in thread
From: Stephen Hemminger @ 2021-07-05 16:24 UTC (permalink / raw)
To: Tyler Blair; +Cc: users
On Mon, 05 Jul 2021 07:05:14 -0400
"Tyler Blair" <tblair@fastmail.com> wrote:
> Hi Stephen,
>
> > Some of the Linux distros have packaged those intokernels extras type packages.
> > In order to support the tap flow emulation you need to hve the ingress qdisc
> > and the flower qdisc. Some of the Linux distros have packaged those into
> > kernels extras type packages.
>
> I installed *linux-azure-lts-20.04* and *linux-modules-extra-azure-lts-20.04* to no avail - is this the extras package you are referring to? The extra one maps to *linux-modules-extra-5.4.0-1051-azure*.
>
> > Or just use netvsc PMD and avoid the problem.
>
> This is what we use ( --vdev=net_vdev_netvsc0,iface=eth1 ) so I expect the messages are harmless - just wanted to check if there was a way to hide the message.
>
> Regards,
> Tyler
What does the following give:
~ $ /sbin/modinfo cls_flower
filename: /lib/modules/5.10.0-7-amd64/kernel/net/sched/cls_flower.ko
license: GPL v2
description: Flower classifier
author: Jiri Pirko <jiri@resnulli.us>
~ $ /sbin/modinfo sch_ingress
filename: /lib/modules/5.10.0-7-amd64/kernel/net/sched/sch_ingress.ko
license: GPL
alias: sch_clsact
depends:
retpoline: Y
intree: Y
name: sch_ingress
vermagic: 5.10.0-7-amd64 SMP mod_unload modversions
Also check kernel log with dmesg.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-users] qdisc errors on 20.11.1 & Azure
2021-07-05 16:24 ` Stephen Hemminger
@ 2021-07-06 14:35 ` Tyler Blair
2021-07-06 14:57 ` Stephen Hemminger
0 siblings, 1 reply; 9+ messages in thread
From: Tyler Blair @ 2021-07-06 14:35 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: users
> What does the following give:
>
> ~ $ /sbin/modinfo cls_flower
~$ /sbin/modinfo cls_flower
filename: /lib/modules/5.8.0-1036-azure/kernel/net/sched/cls_flower.ko
license: GPL v2
description: Flower classifier
author: Jiri Pirko <jiri@resnulli.us>
srcversion: C4CA4ABDCF19EDF40F6D4FA
depends:
retpoline: Y
intree: Y
name: cls_flower
vermagic: 5.8.0-1036-azure SMP mod_unload modversions
sig_id: PKCS#7
signer: Build time autogenerated kernel key
sig_key: 7F:63:F5:F2:69:BF:92:AB:9B:0E:1E:42:92:BB:FC:69:9F:F4:D2:CF
sig_hashalgo: sha512
signature: 11:8D:30:B6:A2:43:CB:2D:82:9B:69:2E:FD:06:75:16:9D:68:F4:58:
11:CD:F5:15:BE:05:6B:85:5B:3A:0F:65:8B:94:38:46:69:4C:9E:1A:
1F:36:1A:1A:05:50:7A:23:CF:B5:48:1E:9A:8E:74:33:81:49:D7:B9:
34:AA:C7:B2:5A:DA:1F:C1:DF:09:FC:9C:20:DA:E8:3D:59:24:EE:D6:
88:65:EC:25:1C:B9:B7:B4:E3:9A:75:FD:E9:81:3F:47:C4:17:37:7E:
CE:08:0F:66:8E:FF:4D:B7:0F:6F:ED:44:99:A6:F9:FF:47:DA:D3:99:
0F:4D:A9:74:2D:E1:D4:06:DE:BB:D9:F0:1A:7D:6A:71:31:01:17:81:
1F:9B:D2:FF:59:D8:FA:36:7D:09:E4:31:66:00:75:3C:1E:52:6F:C3:
F0:B0:F5:B0:24:AC:C7:D6:35:73:63:42:6B:9E:AF:F8:BE:B5:0A:7A:
63:C1:36:39:1C:5C:2C:36:3C:51:6F:C6:DF:42:36:1A:81:BD:0A:D7:
54:64:4B:BE:63:88:07:5E:EE:A2:15:4C:8D:84:85:06:8E:32:5C:4A:
86:B4:A2:9A:9A:D7:5F:43:B0:9E:A1:2B:23:4F:02:BC:FC:43:5E:AF:
03:47:2F:50:18:41:44:27:89:37:1E:1D:C2:26:2A:EB:E6:26:E9:FA:
30:AA:01:75:C5:0A:16:CE:F5:56:A5:50:D5:55:A7:8C:8E:5B:E4:22:
7C:62:75:8C:47:EE:7A:91:12:22:28:DB:95:D2:02:BA:03:31:DD:1A:
D4:71:67:2E:D7:16:F6:B9:AD:F2:2C:9E:15:EA:B2:F4:FE:B7:8F:71:
40:AB:49:0F:37:B1:03:22:70:0A:56:32:2A:35:A5:98:12:0E:10:E4:
14:AF:A2:04:0A:29:54:49:ED:E2:ED:84:8D:52:32:E2:0C:83:FF:D8:
9F:68:29:4F:68:F6:A5:2E:0B:7F:CD:BE:D2:1F:44:DF:9C:F8:B7:A3:
11:75:76:51:17:4E:AA:2E:09:37:BF:65:C7:AF:92:3F:F7:0C:80:A1:
36:42:4C:E6:CA:03:E3:21:6F:41:8A:FF:1A:40:38:B4:4F:FA:F4:EB:
15:B2:48:32:8C:5B:4C:B9:23:75:7B:90:8A:5E:26:D2:5C:75:04:3E:
8F:1D:EA:EC:27:7B:84:85:E2:9A:72:49:07:CF:FC:A3:72:9D:98:2F:
BC:CC:80:06:29:60:8F:82:0A:EF:E6:D7:CA:F1:A8:C8:E2:6D:15:61:
78:8F:2F:F2:BD:1A:28:95:5E:DB:F9:40:C9:33:AA:72:B7:0A:84:E0:
5F:4B:00:3C:0B:ED:E0:69:59:51:D6:86
> What does the following give:
>
> ~ $ /sbin/modinfo sch_ingress
~$ /sbin/modinfo sch_ingress
filename: /lib/modules/5.8.0-1036-azure/kernel/net/sched/sch_ingress.ko
license: GPL
alias: sch_clsact
srcversion: EBF77A2FC1E32262EB9808E
depends:
retpoline: Y
intree: Y
name: sch_ingress
vermagic: 5.8.0-1036-azure SMP mod_unload modversions
sig_id: PKCS#7
signer: Build time autogenerated kernel key
sig_key: 7F:63:F5:F2:69:BF:92:AB:9B:0E:1E:42:92:BB:FC:69:9F:F4:D2:CF
sig_hashalgo: sha512
signature: 27:76:2E:F8:57:92:4A:BA:DA:AB:55:44:A5:2B:05:01:2A:A2:78:B5:
A3:D9:68:FB:C7:FF:6F:4A:F2:BB:82:07:F8:18:43:A1:C7:E4:64:0A:
14:D6:D8:B4:10:0D:C7:8A:C7:93:8F:A2:4E:2D:96:D5:25:BF:16:FE:
72:38:C1:E9:30:BB:FD:C2:F9:B4:08:E8:58:5A:E6:AA:22:75:9F:36:
DF:B6:22:E6:9B:DA:59:DA:81:11:87:19:FD:9E:CC:FF:82:D2:08:92:
10:7D:53:87:FA:10:A4:6D:05:00:40:3A:AD:A2:9B:41:2E:C4:FC:19:
A8:AB:3D:18:54:D4:8B:F4:3A:5D:23:80:57:49:6B:15:22:06:5B:AF:
0B:52:63:F3:05:8F:C3:5B:38:C8:8E:B6:69:C6:D1:77:37:16:65:58:
6F:95:22:0B:BE:EB:93:56:56:E9:7A:02:2C:6B:7D:D7:CB:AF:49:73:
FB:E5:36:19:99:A5:51:94:44:83:AE:25:FD:6B:9B:57:E1:6B:60:62:
68:1F:9C:E2:A7:74:0C:15:4C:FB:CC:08:1F:CD:36:72:38:E0:FD:C7:
E0:43:63:B6:2D:EC:88:7F:9A:91:00:2B:34:B0:2E:27:9E:82:20:84:
B1:AF:8D:8D:01:B5:C6:40:D7:68:DD:80:3A:F7:C2:B4:2D:45:E6:D4:
F0:FA:B2:04:C5:F1:F6:3F:5D:80:04:1E:80:89:FD:7F:9F:C0:06:2E:
F8:D1:FF:DE:71:AA:47:4F:23:7D:09:3B:E4:91:0B:FA:3F:B3:3C:BD:
78:91:2B:AE:5E:E8:0B:39:27:75:90:0A:40:C3:CD:24:E6:79:D8:B6:
15:38:FE:50:DC:55:D0:1B:B2:64:52:BA:ED:47:64:AF:4B:15:CC:18:
BB:8E:B2:B3:3F:3C:F5:BE:AF:81:12:52:95:1F:AE:B5:35:71:14:F5:
DC:69:39:84:F7:FB:4E:16:B5:C4:3F:0B:F5:2C:F9:25:6F:0B:47:09:
0E:06:36:5F:13:FE:BE:B3:C4:FA:D7:D8:67:7C:3B:F9:0D:A0:CA:3D:
B9:D5:23:AC:A9:25:C0:2E:75:66:0C:00:DD:CB:B8:1C:2B:2D:8A:4B:
DB:EE:F4:91:36:E5:F0:24:27:66:5B:72:16:30:EE:A6:9B:21:67:25:
1F:56:60:8E:06:F0:41:51:46:45:99:2F:4E:C7:C1:73:A9:92:34:71:
84:7D:D1:1F:F2:82:C7:4F:AE:89:09:69:4A:D2:58:CA:DC:B7:50:4D:
A5:86:CA:A6:E5:FE:A0:7C:60:45:5F:99:0D:25:00:A3:69:6D:82:26:
3B:9C:B8:2C:6B:60:64:67:06:68:6C:12
> Also check kernel log with dmesg.
Strangely nothing seems amiss there either. Starting/stopping dpdk looks OK as well:
[ 38.796800] Mirror/redirect action on
[ 39.200310] device enP24279s2 entered promiscuous mode
[ 39.200331] mlx5_core 5ed7:00:02.0 enP24279s2: S-tagged traffic will be dropped while C-tag vlan stripping is enabled
[ 39.267874] device eth1 entered promiscuous mode
[ 39.268059] device dtap0 entered promiscuous mode
[ 42.006618] device eth1 left promiscuous mode
I attached the dmesg.txt but nothing really stands out as being unusual.
I haven't been able to test with ConnectX-3 yet - unsure if that card would make a difference but our VMs are currently quite attached to X-4 :)
I updated the kernel from 5.4.0-1051-azure to 5.8.0-1036-azure (with the server-backports ppa workaround) and still seem to receive the warnings.
I don't think I included the full testpmd cmd I'm running in an earlier message, but it's pretty straightforward:
sudo /usr/local/bin/dpdk-testpmd -w 5ed7:00:02.0 --vdev=net_vdev_netvsc0,iface=eth1
Regards,
Tyler
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmesg.txt
URL: <http://mails.dpdk.org/archives/users/attachments/20210706/63509dc8/attachment.txt>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-users] qdisc errors on 20.11.1 & Azure
2021-07-06 14:35 ` Tyler Blair
@ 2021-07-06 14:57 ` Stephen Hemminger
2021-07-06 16:10 ` Tyler Blair
0 siblings, 1 reply; 9+ messages in thread
From: Stephen Hemminger @ 2021-07-06 14:57 UTC (permalink / raw)
To: Tyler Blair; +Cc: users, Long Li
On Tue, 06 Jul 2021 10:35:27 -0400
"Tyler Blair" <tblair@fastmail.com> wrote:
> > What does the following give:
> >
> > ~ $ /sbin/modinfo cls_flower
>
> ~$ /sbin/modinfo cls_flower
> filename: /lib/modules/5.8.0-1036-azure/kernel/net/sched/cls_flower.ko
> license: GPL v2
> description: Flower classifier
> author: Jiri Pirko <jiri@resnulli.us>
> srcversion: C4CA4ABDCF19EDF40F6D4FA
> depends:
> retpoline: Y
> intree: Y
> name: cls_flower
> vermagic: 5.8.0-1036-azure SMP mod_unload modversions
> sig_id: PKCS#7
> signer: Build time autogenerated kernel key
> sig_key: 7F:63:F5:F2:69:BF:92:AB:9B:0E:1E:42:92:BB:FC:69:9F:F4:D2:CF
> sig_hashalgo: sha512
> signature: 11:8D:30:B6:A2:43:CB:2D:82:9B:69:2E:FD:06:75:16:9D:68:F4:58:
> 11:CD:F5:15:BE:05:6B:85:5B:3A:0F:65:8B:94:38:46:69:4C:9E:1A:
> 1F:36:1A:1A:05:50:7A:23:CF:B5:48:1E:9A:8E:74:33:81:49:D7:B9:
> 34:AA:C7:B2:5A:DA:1F:C1:DF:09:FC:9C:20:DA:E8:3D:59:24:EE:D6:
> 88:65:EC:25:1C:B9:B7:B4:E3:9A:75:FD:E9:81:3F:47:C4:17:37:7E:
> CE:08:0F:66:8E:FF:4D:B7:0F:6F:ED:44:99:A6:F9:FF:47:DA:D3:99:
> 0F:4D:A9:74:2D:E1:D4:06:DE:BB:D9:F0:1A:7D:6A:71:31:01:17:81:
> 1F:9B:D2:FF:59:D8:FA:36:7D:09:E4:31:66:00:75:3C:1E:52:6F:C3:
> F0:B0:F5:B0:24:AC:C7:D6:35:73:63:42:6B:9E:AF:F8:BE:B5:0A:7A:
> 63:C1:36:39:1C:5C:2C:36:3C:51:6F:C6:DF:42:36:1A:81:BD:0A:D7:
> 54:64:4B:BE:63:88:07:5E:EE:A2:15:4C:8D:84:85:06:8E:32:5C:4A:
> 86:B4:A2:9A:9A:D7:5F:43:B0:9E:A1:2B:23:4F:02:BC:FC:43:5E:AF:
> 03:47:2F:50:18:41:44:27:89:37:1E:1D:C2:26:2A:EB:E6:26:E9:FA:
> 30:AA:01:75:C5:0A:16:CE:F5:56:A5:50:D5:55:A7:8C:8E:5B:E4:22:
> 7C:62:75:8C:47:EE:7A:91:12:22:28:DB:95:D2:02:BA:03:31:DD:1A:
> D4:71:67:2E:D7:16:F6:B9:AD:F2:2C:9E:15:EA:B2:F4:FE:B7:8F:71:
> 40:AB:49:0F:37:B1:03:22:70:0A:56:32:2A:35:A5:98:12:0E:10:E4:
> 14:AF:A2:04:0A:29:54:49:ED:E2:ED:84:8D:52:32:E2:0C:83:FF:D8:
> 9F:68:29:4F:68:F6:A5:2E:0B:7F:CD:BE:D2:1F:44:DF:9C:F8:B7:A3:
> 11:75:76:51:17:4E:AA:2E:09:37:BF:65:C7:AF:92:3F:F7:0C:80:A1:
> 36:42:4C:E6:CA:03:E3:21:6F:41:8A:FF:1A:40:38:B4:4F:FA:F4:EB:
> 15:B2:48:32:8C:5B:4C:B9:23:75:7B:90:8A:5E:26:D2:5C:75:04:3E:
> 8F:1D:EA:EC:27:7B:84:85:E2:9A:72:49:07:CF:FC:A3:72:9D:98:2F:
> BC:CC:80:06:29:60:8F:82:0A:EF:E6:D7:CA:F1:A8:C8:E2:6D:15:61:
> 78:8F:2F:F2:BD:1A:28:95:5E:DB:F9:40:C9:33:AA:72:B7:0A:84:E0:
> 5F:4B:00:3C:0B:ED:E0:69:59:51:D6:86
>
> > What does the following give:
> >
> > ~ $ /sbin/modinfo sch_ingress
>
> ~$ /sbin/modinfo sch_ingress
> filename: /lib/modules/5.8.0-1036-azure/kernel/net/sched/sch_ingress.ko
> license: GPL
> alias: sch_clsact
> srcversion: EBF77A2FC1E32262EB9808E
> depends:
> retpoline: Y
> intree: Y
> name: sch_ingress
> vermagic: 5.8.0-1036-azure SMP mod_unload modversions
> sig_id: PKCS#7
> signer: Build time autogenerated kernel key
> sig_key: 7F:63:F5:F2:69:BF:92:AB:9B:0E:1E:42:92:BB:FC:69:9F:F4:D2:CF
> sig_hashalgo: sha512
> signature: 27:76:2E:F8:57:92:4A:BA:DA:AB:55:44:A5:2B:05:01:2A:A2:78:B5:
> A3:D9:68:FB:C7:FF:6F:4A:F2:BB:82:07:F8:18:43:A1:C7:E4:64:0A:
> 14:D6:D8:B4:10:0D:C7:8A:C7:93:8F:A2:4E:2D:96:D5:25:BF:16:FE:
> 72:38:C1:E9:30:BB:FD:C2:F9:B4:08:E8:58:5A:E6:AA:22:75:9F:36:
> DF:B6:22:E6:9B:DA:59:DA:81:11:87:19:FD:9E:CC:FF:82:D2:08:92:
> 10:7D:53:87:FA:10:A4:6D:05:00:40:3A:AD:A2:9B:41:2E:C4:FC:19:
> A8:AB:3D:18:54:D4:8B:F4:3A:5D:23:80:57:49:6B:15:22:06:5B:AF:
> 0B:52:63:F3:05:8F:C3:5B:38:C8:8E:B6:69:C6:D1:77:37:16:65:58:
> 6F:95:22:0B:BE:EB:93:56:56:E9:7A:02:2C:6B:7D:D7:CB:AF:49:73:
> FB:E5:36:19:99:A5:51:94:44:83:AE:25:FD:6B:9B:57:E1:6B:60:62:
> 68:1F:9C:E2:A7:74:0C:15:4C:FB:CC:08:1F:CD:36:72:38:E0:FD:C7:
> E0:43:63:B6:2D:EC:88:7F:9A:91:00:2B:34:B0:2E:27:9E:82:20:84:
> B1:AF:8D:8D:01:B5:C6:40:D7:68:DD:80:3A:F7:C2:B4:2D:45:E6:D4:
> F0:FA:B2:04:C5:F1:F6:3F:5D:80:04:1E:80:89:FD:7F:9F:C0:06:2E:
> F8:D1:FF:DE:71:AA:47:4F:23:7D:09:3B:E4:91:0B:FA:3F:B3:3C:BD:
> 78:91:2B:AE:5E:E8:0B:39:27:75:90:0A:40:C3:CD:24:E6:79:D8:B6:
> 15:38:FE:50:DC:55:D0:1B:B2:64:52:BA:ED:47:64:AF:4B:15:CC:18:
> BB:8E:B2:B3:3F:3C:F5:BE:AF:81:12:52:95:1F:AE:B5:35:71:14:F5:
> DC:69:39:84:F7:FB:4E:16:B5:C4:3F:0B:F5:2C:F9:25:6F:0B:47:09:
> 0E:06:36:5F:13:FE:BE:B3:C4:FA:D7:D8:67:7C:3B:F9:0D:A0:CA:3D:
> B9:D5:23:AC:A9:25:C0:2E:75:66:0C:00:DD:CB:B8:1C:2B:2D:8A:4B:
> DB:EE:F4:91:36:E5:F0:24:27:66:5B:72:16:30:EE:A6:9B:21:67:25:
> 1F:56:60:8E:06:F0:41:51:46:45:99:2F:4E:C7:C1:73:A9:92:34:71:
> 84:7D:D1:1F:F2:82:C7:4F:AE:89:09:69:4A:D2:58:CA:DC:B7:50:4D:
> A5:86:CA:A6:E5:FE:A0:7C:60:45:5F:99:0D:25:00:A3:69:6D:82:26:
> 3B:9C:B8:2C:6B:60:64:67:06:68:6C:12
>
> > Also check kernel log with dmesg.
>
> Strangely nothing seems amiss there either. Starting/stopping dpdk looks OK as well:
>
> [ 38.796800] Mirror/redirect action on
> [ 39.200310] device enP24279s2 entered promiscuous mode
> [ 39.200331] mlx5_core 5ed7:00:02.0 enP24279s2: S-tagged traffic will be dropped while C-tag vlan stripping is enabled
> [ 39.267874] device eth1 entered promiscuous mode
> [ 39.268059] device dtap0 entered promiscuous mode
> [ 42.006618] device eth1 left promiscuous mode
>
> I attached the dmesg.txt but nothing really stands out as being unusual.
>
> I haven't been able to test with ConnectX-3 yet - unsure if that card would make a difference but our VMs are currently quite attached to X-4 :)
>
> I updated the kernel from 5.4.0-1051-azure to 5.8.0-1036-azure (with the server-backports ppa workaround) and still seem to receive the warnings.
>
> I don't think I included the full testpmd cmd I'm running in an earlier message, but it's pretty straightforward:
>
> sudo /usr/local/bin/dpdk-testpmd -w 5ed7:00:02.0 --vdev=net_vdev_netvsc0,iface=eth1
>
> Regards,
> Tyler
>
The next thing to check is version of rdma-core. Long just diagnosed an issue with rdma-core version in Ubuntu 20.4
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-users] qdisc errors on 20.11.1 & Azure
2021-07-06 14:57 ` Stephen Hemminger
@ 2021-07-06 16:10 ` Tyler Blair
2021-07-07 16:05 ` Long Li
0 siblings, 1 reply; 9+ messages in thread
From: Tyler Blair @ 2021-07-06 16:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: users, Long Li
> The next thing to check is version of rdma-core. Long just diagnosed an issue with rdma-core version in Ubuntu 20.4
That's the version I'm using in my last reply -- from ppa:canonical-server/server-backports: 33.1-1ubuntu1~backport20.04-202103240925~ubuntu20.04.1
Noticed now, but with the new kernal and rdma-core librdmacm-dev from backports there are some new mlx5_pci errors. Appears to be working OK otherwise though.
EAL: Detected 8 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: Detected static linkage of DPDK
EAL: Selected IOVA mode 'VA'
EAL: Probing VFIO support...
EAL: VFIO support initialized
EAL: Probe PCI driver: mlx5_pci (15b3:1016) device: 5ed7:00:02.0 (socket 0)
** mlx5_pci: Failed to allocate Tx DevX UAR (BF)
** mlx5_pci: Failed to allocate Rx DevX UAR (BF)
** mlx5_pci: No available register for Sampler.
** mlx5_pci: Size 0xFFFF is not power of 2, will be aligned to 0x10000.
net_vdev_netvsc: probably using routed NetVSC interface "eth1" (index 3)
tap_nl_dump_ext_ack(): Cannot delete qdisc with handle of zero
tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid
tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid
tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid
tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid
tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid
tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid
tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid
tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid
Warning: NUMA should be configured manually by using --port-numa-config and --ring-numa-config parameters along with --numa.
testpmd: create a new mbuf pool <mb_pool_0>: n=155456, size=2176, socket=0
testpmd: preferred mempool ops selected: ring_mp_mc
Warning! port-topology=paired and odd forward ports number, the last port will pair with itself.
Configuring Port 1 (socket 0)
Port 1: 00:22:48:3B:AB:CC
Checking link statuses...
Marked with ** - these appear to be pretty benign as well though.
Regards,
Tyler
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-users] qdisc errors on 20.11.1 & Azure
2021-07-06 16:10 ` Tyler Blair
@ 2021-07-07 16:05 ` Long Li
2021-07-13 12:56 ` Tyler Blair
0 siblings, 1 reply; 9+ messages in thread
From: Long Li @ 2021-07-07 16:05 UTC (permalink / raw)
To: Tyler Blair, Stephen Hemminger; +Cc: users
Hi Tyler,
Nvidia helped investigate this.
The message "Failed to allocate Tx DevX UAR (BF)" is diagnostic, not error.
We lowered the log level for this to DEBUG in 21.02. If the further UAR allocation with NC mapping succeeds - there is no known issues about PMD operating.
(if both BF/NC fail - no device probing happens, as we saw).
Hence - just ignore the diagnostic message or use 21.05 or apply the commit " net/mlx5: fix UAR allocation diagnostics messages".
Thanks,
Long
> -----Original Message-----
> From: Tyler Blair <tblair@fastmail.com>
> Sent: Tuesday, July 6, 2021 9:11 AM
> To: Stephen Hemminger <stephen@networkplumber.org>
> Cc: users@dpdk.org; Long Li <longli@microsoft.com>
> Subject: Re: [dpdk-users] qdisc errors on 20.11.1 & Azure
>
> > The next thing to check is version of rdma-core. Long just diagnosed
> > an issue with rdma-core version in Ubuntu 20.4
>
> That's the version I'm using in my last reply -- from ppa:canonical-
> server/server-backports: 33.1-1ubuntu1~backport20.04-
> 202103240925~ubuntu20.04.1
>
> Noticed now, but with the new kernal and rdma-core librdmacm-dev from
> backports there are some new mlx5_pci errors. Appears to be working OK
> otherwise though.
>
> EAL: Detected 8 lcore(s)
> EAL: Detected 1 NUMA nodes
> EAL: Detected static linkage of DPDK
> EAL: Selected IOVA mode 'VA'
> EAL: Probing VFIO support...
> EAL: VFIO support initialized
> EAL: Probe PCI driver: mlx5_pci (15b3:1016) device: 5ed7:00:02.0 (socket 0)
> ** mlx5_pci: Failed to allocate Tx DevX UAR (BF)
> ** mlx5_pci: Failed to allocate Rx DevX UAR (BF)
> ** mlx5_pci: No available register for Sampler.
> ** mlx5_pci: Size 0xFFFF is not power of 2, will be aligned to 0x10000.
> net_vdev_netvsc: probably using routed NetVSC interface "eth1" (index 3)
> tap_nl_dump_ext_ack(): Cannot delete qdisc with handle of zero
> tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid
> tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid
> tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid
> tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid
> tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid
> tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid
> tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid
> tap_nl_dump_ext_ack(): Failed to find qdisc with specified classid
> Warning: NUMA should be configured manually by using --port-numa-config
> and --ring-numa-config parameters along with --numa.
> testpmd: create a new mbuf pool <mb_pool_0>: n=155456, size=2176,
> socket=0
> testpmd: preferred mempool ops selected: ring_mp_mc Warning! port-
> topology=paired and odd forward ports number, the last port will pair with
> itself.
> Configuring Port 1 (socket 0)
> Port 1: 00:22:48:3B:AB:CC
> Checking link statuses...
>
> Marked with ** - these appear to be pretty benign as well though.
>
> Regards,
> Tyler
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-users] qdisc errors on 20.11.1 & Azure
2021-07-07 16:05 ` Long Li
@ 2021-07-13 12:56 ` Tyler Blair
0 siblings, 0 replies; 9+ messages in thread
From: Tyler Blair @ 2021-07-13 12:56 UTC (permalink / raw)
To: Long Li, Stephen Hemminger; +Cc: users
Hi Long,
> The message "Failed to allocate Tx DevX UAR (BF)" is diagnostic, not error.
Thanks - do you have any comment on the qdisc messages or do we just safely ignore these as well?
We are using the rdma-core from ppa:canonical-server/server-backports (33.1-1ubuntu1~backport20.04-202103240925~ubuntu20.04.1).
Regards,
Tyler
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-07-20 10:07 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-28 11:36 [dpdk-users] qdisc errors on 20.11.1 & Azure Tyler Blair
2021-06-29 17:43 ` Stephen Hemminger
2021-07-05 11:05 ` Tyler Blair
2021-07-05 16:24 ` Stephen Hemminger
2021-07-06 14:35 ` Tyler Blair
2021-07-06 14:57 ` Stephen Hemminger
2021-07-06 16:10 ` Tyler Blair
2021-07-07 16:05 ` Long Li
2021-07-13 12:56 ` Tyler Blair
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).