Daniele Di Proietto <diproiet...@ovn.org> writes: > 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
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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev