[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKgT0UemjkzHNHvsp5wb4-OcJB0r3tksKKOVpx5tkRAOB2=ipw@mail.gmail.com>
Date: Fri, 29 Apr 2016 12:36:23 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Saeed Mahameed <saeedm@....mellanox.co.il>
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 12:27 PM, Saeed Mahameed
<saeedm@....mellanox.co.il> wrote:
> 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
Thanks. I'll probably resubmit next week after your latest set of 12
patches gets applied.
- Alex
Powered by blists - more mailing lists