Re: Flows! Offload them.

Scott Feldman
2015-02-26T18:16:27Z

On Thu, Feb 26, 2015 at 8:04 AM, Tom Herbert <therbert@google.com> 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?