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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20160615.002205.499467944175786.davem@davemloft.net>
Date:	Wed, 15 Jun 2016 00:22:05 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	alexander.duyck@...il.com
Cc:	tom@...bertland.com, aduyck@...antis.com, netdev@...r.kernel.org,
	intel-wired-lan@...ts.osuosl.org, hannes@...hat.com,
	jesse@...nel.org, jbenc@...hat.com, saeedm@...lanox.com,
	ariel.elior@...gic.com, Dept-GELinuxNICDev@...gic.com,
	eugenia@...lanox.com, jesse.brandeburg@...el.com
Subject: Re: [net-next PATCH 01/15] net: Combine GENEVE and VXLAN port
 offload notifiers into single functions

From: Alexander Duyck <alexander.duyck@...il.com>
Date: Mon, 13 Jun 2016 19:50:02 -0700

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

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

Thanks.