[ovs-dev] Remote OVS feature discovery

Mooney, Sean K sean.k.mooney at intel.com
Tue Aug 16 09:48:47 UTC 2016



> -----Original Message-----
> From: Aaron Conole [mailto:aconole at redhat.com]
> Sent: Monday, August 15, 2016 9:57 PM
> To: Daniele Di Proietto <diproiettod at ovn.org>
> Cc: Mooney, Sean K <sean.k.mooney at intel.com>; dev at openvswitch.org
> Subject: Re: [ovs-dev] Remote OVS feature discovery
> 
> 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.
[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.



More information about the dev mailing list