Comment 23 for bug 1912844

Hello Dan,

> It looks to me like these two statements are in opposition: if OVS is managing an interface via a different datapath, then it won't have ID_NET_DRIVER=openvswitch in its `udevadm info`.
>
> If this is the case, then I think we have a couple of options.

That is correct, I remembered the other datapath types after suggesting the driver approach.

> Firstly, we could scope this down to only handle system datapath interfaces, so that it _is_ true that all the interfaces we're handling are owned by the openvswitch. I don't know enough about how OVS is used (either by us or more generally) to know if this is a reasonable suggestion, so your guidance would be appreciated.

For the specific use case we're testing with right now it would be safe to assume the system datapath, however our product does also support the use of DPDK acceleration which is hinged on the netdev datapath. So I'm afraid leaving that out of scope might come back and bite us before we know it. But I guess it would be reasonable to split the work up in bite sized chunks as long as we allow for supporting this in the design.

> If we can't do that, then I think we need to ask OVS directly, presumably via `ovs-vsctl show` as discussed above. This would require it to be in PATH, of course; avoiding that is a nice-to-have at best, so I think that's fine.

Yes, we would be able to find the interface in the runtime state through `ovs-vsctl` and friends. The `show` sub-command is mostly meant for human readable overview of configuration, so we will probably dive to the depths of the interface and port tables.

Many of the sub-commands support JSON output format, for example:
`ovs-vsctl -f json find interface name=testport`
`ovs-vsctl -f json find port name=testport`