netdev - Re: [RFC PATCH 2/5] mlx5: Add support for UDP tunnel segmentation with outer checksum offload

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: <49111DBA-CDD6-4D19-9D2D-D6E29675A28F@mellanox.com>
Date:	Fri, 29 Apr 2016 01:18:23 +0000
From:	Matthew Finlay <Matt@...lanox.com>
To:	Alexander Duyck <alexander.duyck@...il.com>
CC:	Saeed Mahameed <saeedm@....mellanox.co.il>,
	Alexander Duyck <aduyck@...antis.com>,
	Eugenia Emantayev <eugenia@...lanox.com>,
	"Bruce W Allan" <bruce.w.allan@...el.com>,
	Saeed Mahameed <saeedm@...lanox.com>,
	Linux Netdev List <netdev@...r.kernel.org>,
	intel-wired-lan <intel-wired-lan@...ts.osuosl.org>,
	Ariel Elior <ariel.elior@...gic.com>,
	Michael Chan <mchan@...adcom.com>
Subject: Re: [RFC PATCH 2/5] mlx5: Add support for UDP tunnel segmentation
 with outer checksum offload






>>
>> The mlx5 hardware requires the outer UDP checksum is not set when offloading encapsulated packets.
>
>The Intel documentation said the same thing.  That was due to the fact
>that the hardware didn't computer the outer UDP header checksum.  I
>suspect the Mellanox hardware has the same issue.  Also I have tested
>on a ConnectX-4 board with the latest firmware and what I am seeing is
>that with my patches applied the outer checksum is being correctly
>applied for segmentation offloads.
>
>My thought is that that the hardware appears to ignore the UDP
>checksum so if it is non-zero you cannot guarantee the checksum would
>be correct on the last frame if it is a different size than the rest
>of the segments.  In the case of these patches that issue has been
>resolved as I have precomputed the UDP checksum for the outer UDP
>header and all of the segments will be the same length so there should
>be no variation in the UDP checksum of the outer header.  Unless you
>can tell my exactly the reason why we cannot provide the outer UDP
>checksum I would assume that the reason is due to the fact that the
>hardware doesn't compute it so you cannot handle a fragment on the end
>which is resolved already via GSO_PARTIAL.

I will check internally and verify there are no unforeseen issues with setting the outer UDP checksum in this scenario.

>
>- Alex