2016-08-15 11:39 GMT-07:00 Mooney, Sean K <sean.k.moo...@intel.com>: > > > > > *From:* Daniele Di Proietto [mailto:diproiet...@ovn.org] > *Sent:* Monday, August 15, 2016 6:29 PM > *To:* Mooney, Sean K <sean.k.moo...@intel.com> > *Cc:* dev@openvswitch.org; Loftus, Ciara <ciara.lof...@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 > > > > > > > > 2016-08-15 9:55 GMT-07:00 Mooney, Sean K <sean.k.moo...@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. > > > > > > > > > > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
