Re: [patch net-next v2 8/9] switchdev: introduce Netlink API

[Thomas Graf <tgraf@suug.ch>]

On 09/20/14 at 03:50pm, Alexei Starovoitov wrote:
> I think HW should not be limited by SW abstractions whether
> these abstractions are called flows, n-tuples, bridge or else.
> Really looking forward to see "device reporting the headers as
> header fields (len, offset) and the associated parse graph"
> as the first step.
> 
> Another topic that this discussion didn't cover yet is how this
> all connects to tunnels and what is 'tunnel offloading'.
> imo flow offloading by itself serves only academic interest.

We haven't touched encryption yet either ;-)

Certainly true for the host case. The Linux on TOR case is less
dependant on this and L2/L3 offload w/o encap already has value.

I'm with you though, all of this has little value on the host in
the DC if stateful encap offload is not incorporated. I expect the
HW to provide filters on the outer header plus metadata in the
encap. Actually, this was a follow-up question I had for John as
this is not easily describable with offset/len filters. How would
we represent such capabilities?

The TX side of this was one of the reasons why I initially thought
it would be beneficial to implement a cache like offload as we could
serve an initial encap in SW, do the FIB lookup and offload it
transparently to avoid replicating the FIB in user space.

What seems most feasisble to me right now is to separate the offload
of the encap action from the IP -> dev mapping decision. The eSwitch
would send the first encap for an unknown dest IP to the CPU due
to a miss in the IP mapping table, the CPU would do the FIB lookup,
update the table and send it back.

What do you have in mind?