[ovs-dev] OVN architecture

[Thomas Graf]

On 01/19/15 at 03:13pm, Ben Pfaff wrote:
> 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.

Excellent.

> 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:
> 
>     [...]

If this can be made to work, I'm all for it.

> 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.

Performance is what crossed my mind ;-) In particular in combination
with hardware offload possibilities as being added to the kernel. It
might become interesting to know about the performance capabilities of
the datapath. That said, since some form of datapath capability check
is needed anyway (conntrack, supported encaps, ...) I would assume
that the required framework will be present anyway.