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]
Date:	Thu, 28 Apr 2016 18:59:47 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Matthew Finlay <Matt@...lanox.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

On Thu, Apr 28, 2016 at 6:18 PM, Matthew Finlay <Matt@...lanox.com> wrote:
>
>
>
>
>
>>>
>>> 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.

Thanks.  Any idea how long it should be.  I know I was getting a
auto-reply about people being out until May 1st due to a holiday so I
am just wondering if we should have Dave drop this patch set and I
submit a v2 when you can get me the feedback next week, or if we run
with the patches as-is for now and be prepared to revert if anything
should come up.

- Alex

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ