> -----Original Message----- > From: Aaron Conole [mailto:acon...@redhat.com] > Sent: Monday, August 15, 2016 9:57 PM > To: Daniele Di Proietto <diproiet...@ovn.org> > Cc: Mooney, Sean K <sean.k.moo...@intel.com>; dev@openvswitch.org > Subject: Re: [ovs-dev] Remote OVS feature discovery > > 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. [Mooney, Sean K] hi yes that was also in the back of my mind. There are too classes of thing that would be useful to be able to detect remotely 1 the available feature set (vhost-user,conntrack ...) 2 the current runtime configuration (rundir, dpdk-init...) im sure there are other values which are compilation dependent
I think both are equally important though both server a slightly different purpose. 1 tell me what I can enable and 2 tells me how to use it. e.g. the current ovs rundir tells me where to expect the Vhost-user socket to be created when ovs is the server which is why we need a way to discover this in the odl and ovn case. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
