[ovs-dev] Remote OVS feature discovery

Aaron Conole aconole at redhat.com
Mon Aug 15 20:56:55 UTC 2016


Daniele Di Proietto <diproiettod at ovn.org> writes:

> 2016-08-15 11:39 GMT-07:00 Mooney, Sean K <sean.k.mooney at intel.com>:
>
>>
>>
>>
>>
>> *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.*
>>
> I see.  I'm sure we can come up with other ways to probe the conntrack
> feature that don't require changes to a table.  Perhaps we need some
> changes in OvS, but I don't see why we should involve ovsdb into something
> that can be handled entirely in OpenFlow.
>
>
>>
>>
>> 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.*
>>
>
> Right, the interface to vhostuser client mode doesn't allow that, that's
> why I suggested changing the interface in response to your comments.
>
>
>>
>>
>> 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

Can I add another "feature discovery"?  ;)

X. Current "rundir" directory (which is used to figure out the vhostuser
   server path, among other things).

I am not sure how best to expose this information, but it is required by
neutron.



More information about the dev mailing list