The default `datapath_type` is 'system', so if it is not explicitly specified for a bridge it will not be visible in `ovs-vsctl show` output, but 'system' will still be the `datapath_type` used.
If you configure a system where all bridges have `datapath_type` 'netdev' /sys/class/net/ovs-system will not be there, but /sys/class/net/ovs-netdev will.
You can query Open vSwitch at runtime for which datapath types it supports with `ovs-vsctl get open_vswitch . datapath_types` which would produce '[netdev, system]' as output.
I guess we cannot foresee how this will be plumbed for all future Open vSwitch releases and possible new datapath types, but either `ovs-system` or `ovs-netdev` will always be there in current versions and use cases.
If we want to be opportunistic I guess iterating over the datapath_types list and check for /sys/class/net/ovs-$datapath_type could be a generic approach that may also work for the next datapath_type we currently do not know about.
The default `datapath_type` is 'system', so if it is not explicitly specified for a bridge it will not be visible in `ovs-vsctl show` output, but 'system' will still be the `datapath_type` used.
If you configure a system where all bridges have `datapath_type` 'netdev' /sys/class/ net/ovs- system will not be there, but /sys/class/ net/ovs- netdev will.
You can query Open vSwitch at runtime for which datapath types it supports with `ovs-vsctl get open_vswitch . datapath_types` which would produce '[netdev, system]' as output.
I guess we cannot foresee how this will be plumbed for all future Open vSwitch releases and possible new datapath types, but either `ovs-system` or `ovs-netdev` will always be there in current versions and use cases.
If we want to be opportunistic I guess iterating over the datapath_types list and check for /sys/class/ net/ovs- $datapath_ type could be a generic approach that may also work for the next datapath_type we currently do not know about.