You have been subscribed to a public bug:
This is Jammy/Caracal
nova 3:29.2.0-0ubuntu1.2~cloud0+riscv64.202601141153.1
neutron 2:24.1.0-0ubuntu1~cloud0
openvswitch 3.3.9-0ubuntu0.22.04.1
The cloud uses Open vSwitch with `other_config:hw-offload=true` on a Mellanox
mlx5 switchdev NIC.
We see that flow dump duration reported by `ovs-appctl upcall/show`
scales with the total number of ovs datapath ports.
While investigating this we found that when creating a new VM with a tap
interface, this interface is on boarded to the offload provider even if
this is not needed
in /var/log/openvswitch/ovs-vswitchd.log this appears wen creating a new
non hwol VM:
2026-09-03T10:04:15.366Z|43786|bridge|WARN|could not open network device
tapa16ac7b3-9f (No such device)
2026-09-03T10:04:16.522Z|43790|bridge|WARN|could not open network device
tapa16ac7b3-9f (No such device)
2026-09-03T10:04:20.323Z|43796|netdev_offload_tc|INFO|added ingress qdisc to
tapa16ac7b3-9f
2026-09-03T10:04:20.323Z|43797|netdev_offload|INFO|tapa16ac7b3-9f: Assigned
flow API 'linux_tc'.
2026-09-03T10:04:20.326Z|43798|bridge|INFO|bridge br-int: added interface
tapa16ac7b3-9f on port 257
For ports using the TC flow API (`lib/netdev-offload-tc.c`), this results
in `netdev_tc_flow_dump_create()` issuing one `RTM_GETTFILTER` netlink DUMP
transaction per port, every revalidator sweep, regardless of whether
that port has ever carried a single offloaded flow:
```
netdev_tc_flow_dump_create(struct netdev *netdev, ...)
{
...
id = tc_make_tcf_id(ifindex, block_id, prio, hook);
tc_dump_flower_start(&id, dump->nl_dump, terse);
...
}
```
`netdev_assign_flow_api()` attaches the TC flow API to every Linux
netdev when `hw-offload=true` is set globally — there is no per-port
scoping based on whether the port is actually capable of, or currently
holding, offloaded flows. This means plain VM taps (which never get true
hardware offload) still incur a full TC dump every round, identically to
SR-IOV VF representors that do.
This
https://github.com/openvswitch/ovs/blob/b30f621502752463807af7bb8bcf3a0c763544cf/lib/dpif.c#L371
suggests that ports with type=tap are not onboarded in the offload
provider but currently this is empty in the tap created by Neutron/OVN
# ovs-vsctl get Interface tapa16ac7b3-9f type
""
We tried to set this to tap with
# ovs-vsctl set Interface tapa16ac7b3-9f type=tap
but the VM went unreachable and ovs logged
2026-09-03T10:16:00.291Z|44161|bridge|INFO|bridge br-int: deleted interface
tapa16ac7b3-9f on port 257
2026-09-03T10:16:00.493Z|44162|netdev_linux|WARN|tapa16ac7b3-9f: creating tap
device failed: Device or resource busy
2026-09-03T10:16:00.494Z|44163|bridge|WARN|could not open network device
tapa16ac7b3-9f (Device or resource busy)
2026-09-03T10:16:01.160Z|44164|netdev_linux|WARN|tapa16ac7b3-9f: creating tap
device failed: Device or resource busy
2026-09-03T10:16:01.160Z|44165|bridge|WARN|could not open network device
tapa16ac7b3-9f (Device or resource busy)
Stopping and starting the VM recreated the tap interface with no type and VM
was reachable again
** Affects: openvswitch (Ubuntu)
Importance: Undecided
Status: New
--
Tap interfaces are onboarded on the OVS offload provider
https://bugs.launchpad.net/bugs/2166336
You received this bug notification because you are a member of Ubuntu Bugs,
which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
