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. 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.moo...@intel.com<mailto: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
