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

[Alexander Duyck <alexander.duyck@gmail.com>]

On Fri, Apr 29, 2016 at 12:27 PM, Saeed Mahameed
<saeedm@dev.mellanox.co.il> wrote:
> On Fri, Apr 29, 2016 at 4:59 AM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Thu, Apr 28, 2016 at 6:18 PM, Matthew Finlay <Matt@mellanox.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


Thanks.  I'll probably resubmit next week after your latest set of 12
patches gets applied.

- Alex