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