[ovs-dev] Remote OVS feature discovery

Daniele Di Proietto diproiettod at ovn.org
Mon Aug 15 17:28:35 UTC 2016


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

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.

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.

I'm sure we should be able to do the same with NSH and all the other new
features.


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.

Thanks,

Daniele


>
> 2016-08-15 9:55 GMT-07:00 Mooney, Sean K <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.
>>
>>
>>
>>
>>
>>
>>
>
>



More information about the dev mailing list