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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 29 Apr 2016 22:27:36 +0300
From:	Saeed Mahameed <saeedm@....mellanox.co.il>
To:	Alexander Duyck <alexander.duyck@...il.com>
Cc:	Matthew Finlay <Matt@...lanox.com>,
	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 Fri, Apr 29, 2016 at 4:59 AM, Alexander Duyck
<alexander.duyck@...il.com> wrote:
> 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,

I reviewed your patches and other than  the claim about mlx4,
everything seems to be ok.
I took the liberty to apply your patches and play around with them
only on mlx5 for now,
It seems that it works and HW do correctly calculate the IPv6 outer
UDP sum as illustrated in the log from the tcpdump on the receiver
[1], I also noticed that the GSO also works on the xmitter and the HW
ignores the outer sum as expected.

Matt, I think you still need to do the homework and see if we didn't
miss anything here, but theoretically and practically what Alex did
here should work.
Tariq will also check what went wrong with mlx4 outer ipv6 support,
but this shouldn't block this series.

Side notes:
- Alex, you will need to rebase the series, it didn't apply smoothly.
- BTW mlx5 on RX side will provide csum complete and not csum unnecessary.

Saeed.

[1]
21:28:15.474287 e4:1d:2d:5c:f2:e8 > e4:1d:2d:5c:f2:d4, ethertype IPv6
(0x86dd), length 1514: (hlim 64, next-header UDP (17) payload length:
1460) 2001::37:4.58006 > 2001::36:4.4789: [udp sum ok] VXLAN, flags
[I] (0x08), vni 46
66:cb:6e:a4:31:4e > b6:bf:9b:61:31:62, ethertype IPv4 (0x0800), length
1444: (tos 0x0, ttl 64, id 64920, offset 0, flags [DF], proto TCP (6),
length 1430)
    56.0.37.4.53614 > 56.0.36.4.commplex-link: Flags [.], cksum 0xd6cc
(correct), seq 1911713070:1911714448, ack 1, win 218, options
[nop,nop,TS val 183853011 ecr 183840106], length 1378