[ovs-dev] Remote OVS feature discovery

[Mooney, Sean K]

From: Daniele Di Proietto [mailto:diproiettod at ovn.org]
Sent: Monday, August 15, 2016 6:29 PM
To: Mooney, Sean K <sean.k.mooney at intel.com>
Cc: dev at openvswitch.org; Loftus, Ciara <ciara.loftus at intel.com>
Subject: Re: [ovs-dev] Remote OVS feature discovery

Hi Sean,
I'm not familiar with OpenStack, so I'm not sure that my comments make sense for every possible use case.
I'm not 100% sure an explicit feature discovery interface is required.  If an interface is well designed it should be possible to discover features by "probing".  We never had any problem doing that with the datapath netlink interface, see for example check_support() in ofproto/ofproto-dpif.c
[Mooney, Sean K] in the past OpenStack neutron has not allowed the use of active probing to detect features. We can query the ovsdb but not write to it.
Going feature by feature:
1. Connection tracking
This can easily be detected by trying to set up a flow with a connection tracking action.  If the flow setup succeeds it means that the datapath supports connection tracking.
[Mooney, Sean K] this approach has been reject by the neutron core team in the past though It is something we could bring  up again.
It was previously seen as a potential security risk though if you used a dedicate openflow table that is never otherwise used then
It may  be acceptable. Its been about 2 years since I last suggested actively probing in that case to detect vhost-user before the
iface_types field was added.

2. Nat
Same as connection tracking
3. Vhost-client mode
The interface needs to be redefined.  The fact that's not easy to do feature detection probably means that the interface is not well defined
4. Jumbo frames
We added another column in the Interface table.  By looking at the schema it should be possible to determine if the datapath supports the feature.
[Mooney, Sean K] yes in this case a ovs-vsctl get or similar to check if the column is defined should work well though we can’t check the schema directly and must query the
Ovsdb. This does not work for vhost-client mode as it would be storing the vhost-user socket path in the other_config section of the port as far as I recall.


I'm sure we should be able to do the same with NSH and all the other new features.
[Mooney, Sean K] for nsh assuming we have openflow push/pop action we could possible do an active probe when we started the ovs neutron agent but again last time I suggested this in
Neutron active probes were not accepted.
if ovs-vsctl --dry-run or ovs-ofctl --dry-run can be used to test if a feature can be enabled then that might be accepted in neutron unfortunately this is not the case
for example  sudo ovs-vsctl --dry-run --no-wait add-port br-int fake-port -- set interface fake-port type=fake-type ; echo $?
will print 0 as the command will always succeed as the ovsdb does not validate the type is one of the registered types. The validation
if added would have to be done server side as the client would not always be used i.e when odl is managing ovs.

This is just my opinion based on my experience so far.  If some of the developers think this is too hacky, maybe it's fine to explicitly export the supported features.
[Mooney, Sean K] well the main reason I brought this up is often features are added to ovs that require active probing to detect which to date were not allowed to use in neutron.
the other drawback to this is that for every new feature that is added to ovs we have to come up with a new way to detect if its there or not.
im not sure if exporting  the supported features explicitly is the right solution but  it would provide a standardized interface to check for feature x.
this is more of an open question in general is remote passive ovs feature discovery something that people think is useful or is active probing the only
thing that ovs will support in this regard.
Thanks,
Daniele



2016-08-15 9:55 GMT-07:00 Mooney, Sean K <sean.k.mooney at intel.com<mailto:sean.k.mooney at intel.com>>:
Hi I would like to bring up a recurring problem that
Has arisen several times with enabling new ovs features in
OpenStack.

OpenStack neutron  supports many different network backend
Including ovs which is currently the most common .
As OpenStack has to support multiple versions of ovs both to provide
Multi distro support and to support rolling upgrades new ovs features
That are consumed in openstack must be enabled dynamically based on the
Capabilities of the vswitch on the target server.

An example of this today is vhost-user support. if ovs is compiled with dpdk support
And started with dpdk enabled the ifaces_types field in the Open_vSwitch table will
Contain the dpdk_vhostuser port type. If the dpdk_vhostuser port type is found and the bridges
Datapath type Is netdev then vhost-user is enabled for that platform in neutron.

There are many other feature that cannot be detected remotely today.
The ovs FAQ lists a number of features that are available on different data paths that openstack and other
Systems may care to know about so that it can use that feature when present and
take appropriate action when not. e.g. place vm on a different host running a different ovs version or fallback
to a different code path if a new feature is not available
https://github.com/openvswitch/ovs/blob/master/FAQ.md#q-are-all-features-available-with-all-datapaths

what I would like to ask is if we can introduce a new ovsdb table to declare the features available in the current ovs version.
This would involve converting the current tables in the FAQ feature section in to static entries in the ovsdb schema in a new
Feature table.
Each entry in the table would be readonly and the table can be upgraded in each release by ovsdb-tool convert to migrate/upgreade
The schema of the current db.

Note the reason I am suggesting using the ovsdb to declare the features is that for odl and to a less extent ovn and openstack
The ovsdb is the only interface that can be used to interact with the vswitch remotely.
In the special case of odl neither odl or openstack neutron have an agent on the server running ovs
so only ovsdb and openflow can be used. As a result tools such as ovs-appctl or any of the other ovs-* tools cannot be used
to support this usecase.

Currently there are 3 feature that will require this or a similar feature to enable in openstack.
Those feature are:
Vhost-user reconnect /  vhost- user  qemu:server dpdk:client mode
UserSpace jumbo frames support
Connection tracking

Other features that this would be required for in the future include ovs NAT,QOS polices,NSH and any other feature that is not
Enabled on all datapath concurrently. I would expect that ovn would need a subset of this information to be reported in the chassis table
also in the future to enable more advanced use cases.

Regards
Sean.