[ovs-dev] OVN architecture

Ben Pfaff blp at nicira.com
Mon Jan 19 23:13:49 UTC 2015


On Tue, Jan 20, 2015 at 12:07:52AM +0100, Thomas Graf wrote:
> On 01/19/15 at 09:58am, Ben Pfaff wrote:
> > To keep the discussion going, let's talk about each of those features.
> > 
> > These days, OVS allows an ARP responder can be implemented in the
> > OpenFlow flow table (since all ARP fields are modifiable), but that has
> > only been true for a few versions.  Before that, an ARP responder could
> > only be implemented in an OpenFlow controller.  So to support those
> > older versions, OVN would have to detect support for ARP field
> > modification and divert packets to ovn-controller.  I think
> > ovn-controller will probably need a general framework for that kind of
> > thing, so it's probably feasible.
> 
> Do you have something specific in mind already on how to test
> availability, in particular for existing OVS releases? Configuring a
> dummy flow table with certain matches and actions on startup and
> constructing a list of capabilities based on it?

I think that this can be simply tested for with an OFPT_PACKET_OUT whose
packet is an ARP and whose actions modify ARP header fields and then
send the packet back to the controller.  If the packet comes back in an
OFPT_PACKET_IN, with the requested ARP field values, the feature works.
If an error results, the feature doesn't work.

> For new releases, a new OVSDB could provide capabilities.

I guess I prefer feature tests over capabilities, because it is too easy
to backport a feature while forgetting to backport the capability, or
(worse) to turn on all the capabilities set while forgetting to actually
implement those features.  That is, I tend toward the philosophy
described in the introduction to the Autoconf manual:

       The configuration scripts produced by Autoconf require no manual
    user intervention when run; they do not normally even need an
    argument specifying the system type.  Instead, they individually
    test for the presence of each feature that the software package they
    are for might need.  (Before each check, they print a one-line
    message stating what they are checking for, so the user doesn't get
    too bored while waiting for the script to finish.)  As a result,
    they deal well with systems that are hybrids or customized from the
    more common Posix variants.  There is no need to maintain files that
    list the features supported by each release of each variant of
    Posix.

> > But maybe by "ARP responder" you don't mean the ability to respond to
> > ARP requests but the ability to synthesize ARP requests from IP packets,
> > like a router needs to do.  OVN will have to do this to implement L3
> > features.  No current version of OVS can do this from the flow table, so
> > it will have to be implemented by ovn-controller diversion everywhere.
> > This may be acceptable, because ARP isn't that performance sensitive,
> > but perhaps we'll find out that there's good reason to build it into
> > OVS.  Then we'd, again, make OVN probe for support and use one strategy
> > or the other.
> 
> Another minor difference to be taken care of is the capability of
> implementing certain set-fields in the datapath. An example right now
> would be ARP fields which require a user space fall back.

What is there to take care of there?  The userspace fallbacks should be
entirely transparent to the OpenFlow interface.  The only difference is
performance, and generally speaking the userspace fallbacks are there
only in cases where we expect the performance difference not to matter.



More information about the dev mailing list