On Thu, Feb 26, 2015 at 8:04 AM, Tom Herbert [off-list ref] wrote:

Sorry if I'm asking dumb questions, but this is about where I usually
start to get lost in these discussions ;-). Is the aim of switch
offload to offload OVS or kernel functions of routing, iptables, tc,
etc.?

Both, which is why it's hard to follow, and there are active efforts
on both fronts.  What has stuck so far with switchdev is offloading
kernel functions, such as L2 bridging to existing switch chips (real
(DSA) or fake (rocker)).  WIP on extended that to L3 and maybe a
subset of nftables.  So far, the kernel is the "application", and
we're offloading (sorry, overloaded term, but I can't think of an
alternative) the kernel fwd data paths to capable hardware.  But there
are "impedance" mismatches between what we can do today in the kernel
and fixed hardware.  On the other front we have offloading OVS, or
more in more general terms, programming the switch from some other
"application", local or remote using the proposed flow api or tc or
some combination.  Maybe these two fronts merge down the road where
the kernel is just another application using the flow api.  Grand
unification theory?

These are very different I believe. As far as I can tell OVS
model of "flows" (like Openflow) is currently incompatible with the
rest of the kernel.
So if the plan is convert OVS datapath to TC does
that mean introducing that model into core kernel?