Re: [net-next PATCH 01/15] net: Combine GENEVE and VXLAN port offload notifiers into single functions

On Wed, Jun 15, 2016 at 12:22 AM, David Miller [off-list ref] wrote:

From: Alexander Duyck <redacted>
Date: Mon, 13 Jun 2016 19:50:02 -0700

quoted

I'm not going to speculate on what Dave's opinion on this is.  I'll
wait to hear it from him.

My concern at this point is that we have several issues.  Specifically
we have VXLAN-GPE trying to pass itself off as VXLAN when it clearly
is not, and I know we are going to end up with somebody eventually
trying to push this feature into the kernel.  I know for a fact there
is hardware out there that already supports it.  I'm trying to get
ahead of this and define what the interface is supposed to look like
myself so that we don't end up with somebody unfamiliar with all this
trying to push it.  This way we can avoid having some hardware vendor
on a timeline trying to push it through quick as in the case of i40e,
or somebody trying to get around it by just hard coding it into their
driver like occurred with bnxt.

While I appreciate the opinion, outright refusing to enable the
existing offloads is counterproductive.  There are customers out there
that already have this hardware.  There are driver writers out there
who are going to have to enable these features one way or another.  If
we want to be obstructionists then I am sure they can just work around
us and write up out-of-tree drivers and use something like module
parameters to enable offloads on a specific port.  Most of these
implementations only seem to support one port anyway.  I just thought
it might be better to have this figured out in the kernel so that we
didn't end up creating a bigger mess than needed with each vendor
going off and doing their own out-of-tree implementation.

My plan is to try and properly balance the two side of this situation.

Realistically, and Alex is right on this, we shoot ourselves in the
foot by not supporting offloads that exist in hardware now even if
they are not generic.

It was the interface that was rejected not any particular hardware
offload. We pointed out that n-tuple filtering is a much better
interface anyway allowing address binding and implementing offload for
new protocols without needed to change common header files. Besides,
if it's really just about VXLAN-GPE and that is the last of the
protocols in the three year HW pipeline then we can add another ndo
function specific for that.

Personally, I think the question of protocol specific offloads is moot
anyway. In the past six months the world since this issue came up the
world has moved forward. We have a lot better support for generic
offloads (Alex's patches on that), GRO for UDP is based on socket
lookup instead alternate lookup destination port, LCO has been
integrated, real support for ipxip6, extension headers being developed
that are going to be deployed, ILA allows virtualization without
encapsulation (no HW support needed), more IPv6 deployment in general,
MPLS/UDP is now an Internet standard, GRE/UDP will go to WGLC in IETF
soon, even more encapsulation protocols like IP/UDP have been
proposed, QUIC is being deployed and probably going to be a WG, first
TOU patches will soon be upstream, FD.io and DPDK are still making a
big fuss to bypass the kernel-- XDP is proving the kernel is not
problem, we now have first instances of truly programmable NICs using
BPF which is the path to truly generic offloads. This is really quite
an impressive list for sure! I don't see that protocol specific
offloads figure into much of this.

Tom

So I would encourage Alex to keep working on his patch set and to
keep working on the feedback he is given.

Thanks.