netdev - Re: [net-next PATCH v3 17/17] vxlan: Add new UDP encapsulation offload type for VXLAN-GPE

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 for Android: free password hash cracker in your pocket

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

Message-ID: <cd97e62f-9513-99c6-3f47-d849b268ef17@stressinduktion.org>
Date:	Fri, 17 Jun 2016 01:01:38 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Alexander Duyck <aduyck@...antis.com>, netdev@...r.kernel.org,
	intel-wired-lan@...ts.osuosl.org
Cc:	jesse@...nel.org, eugenia@...lanox.com, jbenc@...hat.com,
	alexander.duyck@...il.com, saeedm@...lanox.com,
	ariel.elior@...gic.com, tom@...bertland.com,
	michael.chan@...adcom.com, Dept-GELinuxNICDev@...gic.com,
	davem@...emloft.net
Subject: Re: [net-next PATCH v3 17/17] vxlan: Add new UDP encapsulation
 offload type for VXLAN-GPE

On 16.06.2016 21:23, Alexander Duyck wrote:
> The fact is VXLAN with Generic Protocol Extensions cannot be supported by
> the same hardware parsers that support VXLAN.  The protocol extensions
> allow for things like a Next Protocol field which in turn allows for things
> other than Ethernet to be passed over the tunnel.  Most existing parsers
> will not know how to interpret this.
> 
> To resolve this I am giving VXLAN-GPE its own UDP encapsulation offload
> type.  This way hardware that does support GPE can simply add this type to
> the switch statement for VXLAN, and if they don't support it then this will
> fix any issues where headers might be interpreted incorrectly.
> 
> Signed-off-by: Alexander Duyck <aduyck@...antis.com>

Acked-by: Hannes Frederic Sowa <hannes@...essinduktion.org>