[ovs-dev] Querying OVS for OpenFlow capabilities

Justin Pettit jpettit at ovn.org
Thu Sep 12 18:46:41 UTC 2019



> On Sep 12, 2019, at 11:08 AM, Mark Michelson <mmichels at redhat.com> wrote:
> 
> Hi guys,
> 
> I recently sent a new version of a document describing proposed OVN/OVS compatibility [1]. In it, I suggested that when we add new OpenFlow capabilities to OVS, then OVN needs to probe OVS for the OpenFlow capabilities at startup. This way we can know whether we have the capability, can log an informational message, and can just generally be as graceful as possible.
> 
> Numan brought up that the ability to probe at runtime for an OpenFlow feature may not exist yet. I'm aware right now that we could attempt to program a flow that uses the capability we're interested in and see if it succeeds. But I was wondering if there's a more formal way of doing it.

Thanks for writing up that document.  I do think probing is the best way to do it.  We do similar feature probing of the datapath in ovs-vswitchd (see dpif_probe_feature() in lib/dpif.c).

This brings up another wrinkle: datapath compatibility.  Feature support changes depending on the datapath, and there's starting to be a proliferation of datapaths (upstream Linux kernel datapath, OVS Linux kernel datapath, Windows datapath, and userspace datapath).  These have different features that can affect the ability to make OVS work as the controller expects.

William (cc'd) is looking at adding a new feature compatibility column to the Datapath table that should be landing in master this week.  This will allow a controller to probe for datapath-level features.  (And some of those could probably be proxies for OpenFlow-level support for features.)  I'm not sure if he's started coding it yet, though.

Anyway, something else you may want to keep an eye on.

--Justin




More information about the dev mailing list