| Message ID | 20160419190603.11723.31623.stgit@ahduyck-xeon-server |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
On Tue, Apr 19, 2016 at 10:06 PM, Alexander Duyck <aduyck@mirantis.com> wrote: > This patch assumes that the mlx5 hardware will ignore existing IPv4/v6 > header fields for length and checksum as well as the length and checksum > fields for outer UDP headers. > > I have no means of testing this as I do not have any mlx5 hardware but > thought I would submit it as an RFC to see if anyone out there wants to > test this and see if this does in fact enable this functionality allowing > us to to segment UDP tunneled frames that have an outer checksum. > > Signed-off-by: Alexander Duyck <aduyck@mirantis.com> > --- > drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c > index e0adb604f461..57d8da796d50 100644 > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c > @@ -2390,13 +2390,18 @@ static void mlx5e_build_netdev(struct net_device *netdev) > netdev->hw_features |= NETIF_F_HW_VLAN_CTAG_FILTER; > > if (mlx5e_vxlan_allowed(mdev)) { > - netdev->hw_features |= NETIF_F_GSO_UDP_TUNNEL; > + netdev->hw_features |= NETIF_F_GSO_UDP_TUNNEL | > + NETIF_F_GSO_UDP_TUNNEL_CSUM | > + NETIF_F_GSO_PARTIAL; > netdev->hw_enc_features |= NETIF_F_IP_CSUM; > netdev->hw_enc_features |= NETIF_F_RXCSUM; > netdev->hw_enc_features |= NETIF_F_TSO; > netdev->hw_enc_features |= NETIF_F_TSO6; > netdev->hw_enc_features |= NETIF_F_RXHASH; > netdev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL; > + netdev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL_CSUM | > + NETIF_F_GSO_PARTIAL; > + netdev->gso_partial_features = NETIF_F_GSO_UDP_TUNNEL_CSUM; > } > > netdev->features = netdev->hw_features; > Hi Alex, Adding Matt, VxLAN feature owner from Mellanox, Matt please correct me if am wrong, but We already tested GSO VxLAN and we saw the TCP/IP checksum offloads for both inner and outer headers handled by the hardware. And looking at mlx5e_sq_xmit: if (likely(skb->ip_summed == CHECKSUM_PARTIAL)) { eseg->cs_flags = MLX5_ETH_WQE_L3_CSUM; if (skb->encapsulation) { eseg->cs_flags |= MLX5_ETH_WQE_L3_INNER_CSUM | MLX5_ETH_WQE_L4_INNER_CSUM; sq->stats.csum_offload_inner++; } else { eseg->cs_flags |= MLX5_ETH_WQE_L4_CSUM; } We enable inner/outer hardware checksumming unconditionally without looking at the features Alex is suggesting in this patch, Alex, can you elaborate more on the meaning of those features ? and why would it work for us without declaring them ?
On Wed, Apr 20, 2016 at 10:40 AM, Saeed Mahameed <saeedm@dev.mellanox.co.il> wrote: > On Tue, Apr 19, 2016 at 10:06 PM, Alexander Duyck <aduyck@mirantis.com> wrote: >> This patch assumes that the mlx5 hardware will ignore existing IPv4/v6 >> header fields for length and checksum as well as the length and checksum >> fields for outer UDP headers. >> >> I have no means of testing this as I do not have any mlx5 hardware but >> thought I would submit it as an RFC to see if anyone out there wants to >> test this and see if this does in fact enable this functionality allowing >> us to to segment UDP tunneled frames that have an outer checksum. >> >> Signed-off-by: Alexander Duyck <aduyck@mirantis.com> >> --- >> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 7 ++++++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c >> index e0adb604f461..57d8da796d50 100644 >> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c >> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c >> @@ -2390,13 +2390,18 @@ static void mlx5e_build_netdev(struct net_device *netdev) >> netdev->hw_features |= NETIF_F_HW_VLAN_CTAG_FILTER; >> >> if (mlx5e_vxlan_allowed(mdev)) { >> - netdev->hw_features |= NETIF_F_GSO_UDP_TUNNEL; >> + netdev->hw_features |= NETIF_F_GSO_UDP_TUNNEL | >> + NETIF_F_GSO_UDP_TUNNEL_CSUM | >> + NETIF_F_GSO_PARTIAL; >> netdev->hw_enc_features |= NETIF_F_IP_CSUM; >> netdev->hw_enc_features |= NETIF_F_RXCSUM; >> netdev->hw_enc_features |= NETIF_F_TSO; >> netdev->hw_enc_features |= NETIF_F_TSO6; >> netdev->hw_enc_features |= NETIF_F_RXHASH; >> netdev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL; >> + netdev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL_CSUM | >> + NETIF_F_GSO_PARTIAL; >> + netdev->gso_partial_features = NETIF_F_GSO_UDP_TUNNEL_CSUM; >> } >> >> netdev->features = netdev->hw_features; >> > > Hi Alex, > > Adding Matt, VxLAN feature owner from Mellanox, > Matt please correct me if am wrong, but We already tested GSO VxLAN > and we saw the TCP/IP checksum offloads for both inner and outer > headers handled by the hardware. > > And looking at mlx5e_sq_xmit: > > if (likely(skb->ip_summed == CHECKSUM_PARTIAL)) { > eseg->cs_flags = MLX5_ETH_WQE_L3_CSUM; > if (skb->encapsulation) { > eseg->cs_flags |= MLX5_ETH_WQE_L3_INNER_CSUM | > MLX5_ETH_WQE_L4_INNER_CSUM; > sq->stats.csum_offload_inner++; > } else { > eseg->cs_flags |= MLX5_ETH_WQE_L4_CSUM; > } > > We enable inner/outer hardware checksumming unconditionally without > looking at the features Alex is suggesting in this patch, > Alex, can you elaborate more on the meaning of those features ? and > why would it work for us without declaring them ? Well right now the feature list exposed by the device indicates that TSO is not used if a VxLAN tunnel has a checksum in an outer header. Since that is not exposed currently that is completely offloaded in software via GSO. What the GSO partial does is allow us to treat GSO for tunnels with checksum like it is GSO for tunnels without checksum by precomputing the UDP checksum as though the frame had already been segmented and restricts us to an even multiple of MSS bytes that are to be segmented between all the frames. One side effect though is that all of the IP and UDP header fields are also precomputed, but from what I can tell it looks like the values that would be changed by a change in length are ignored or overwritten by the hardware and driver anyway. - Alex
On 4/20/16, 11:06 AM, "Alexander Duyck" <alexander.duyck@gmail.com> wrote: >On Wed, Apr 20, 2016 at 10:40 AM, Saeed Mahameed ><saeedm@dev.mellanox.co.il> wrote: >> On Tue, Apr 19, 2016 at 10:06 PM, Alexander Duyck <aduyck@mirantis.com> wrote: >>> This patch assumes that the mlx5 hardware will ignore existing IPv4/v6 >>> header fields for length and checksum as well as the length and checksum >>> fields for outer UDP headers. >>> >>> I have no means of testing this as I do not have any mlx5 hardware but >>> thought I would submit it as an RFC to see if anyone out there wants to >>> test this and see if this does in fact enable this functionality allowing >>> us to to segment UDP tunneled frames that have an outer checksum. >>> >>> Signed-off-by: Alexander Duyck <aduyck@mirantis.com> >>> --- >>> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 7 ++++++- >>> 1 file changed, 6 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c >>> index e0adb604f461..57d8da796d50 100644 >>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c >>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c >>> @@ -2390,13 +2390,18 @@ static void mlx5e_build_netdev(struct net_device *netdev) >>> netdev->hw_features |= NETIF_F_HW_VLAN_CTAG_FILTER; >>> >>> if (mlx5e_vxlan_allowed(mdev)) { >>> - netdev->hw_features |= NETIF_F_GSO_UDP_TUNNEL; >>> + netdev->hw_features |= NETIF_F_GSO_UDP_TUNNEL | >>> + NETIF_F_GSO_UDP_TUNNEL_CSUM | >>> + NETIF_F_GSO_PARTIAL; >>> netdev->hw_enc_features |= NETIF_F_IP_CSUM; >>> netdev->hw_enc_features |= NETIF_F_RXCSUM; >>> netdev->hw_enc_features |= NETIF_F_TSO; >>> netdev->hw_enc_features |= NETIF_F_TSO6; >>> netdev->hw_enc_features |= NETIF_F_RXHASH; >>> netdev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL; >>> + netdev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL_CSUM | >>> + NETIF_F_GSO_PARTIAL; >>> + netdev->gso_partial_features = NETIF_F_GSO_UDP_TUNNEL_CSUM; >>> } >>> >>> netdev->features = netdev->hw_features; >>> >> >> Hi Alex, >> >> Adding Matt, VxLAN feature owner from Mellanox, >> Matt please correct me if am wrong, but We already tested GSO VxLAN >> and we saw the TCP/IP checksum offloads for both inner and outer >> headers handled by the hardware. >> >> And looking at mlx5e_sq_xmit: >> >> if (likely(skb->ip_summed == CHECKSUM_PARTIAL)) { >> eseg->cs_flags = MLX5_ETH_WQE_L3_CSUM; >> if (skb->encapsulation) { >> eseg->cs_flags |= MLX5_ETH_WQE_L3_INNER_CSUM | >> MLX5_ETH_WQE_L4_INNER_CSUM; >> sq->stats.csum_offload_inner++; >> } else { >> eseg->cs_flags |= MLX5_ETH_WQE_L4_CSUM; >> } >> >> We enable inner/outer hardware checksumming unconditionally without >> looking at the features Alex is suggesting in this patch, >> Alex, can you elaborate more on the meaning of those features ? and >> why would it work for us without declaring them ? > >Well right now the feature list exposed by the device indicates that >TSO is not used if a VxLAN tunnel has a checksum in an outer header. >Since that is not exposed currently that is completely offloaded in >software via GSO. The mlx5 hardware requires the outer UDP checksum is not set when offloading encapsulated packets. > >What the GSO partial does is allow us to treat GSO for tunnels with >checksum like it is GSO for tunnels without checksum by precomputing >the UDP checksum as though the frame had already been segmented and >restricts us to an even multiple of MSS bytes that are to be segmented >between all the frames. One side effect though is that all of the IP >and UDP header fields are also precomputed, but from what I can tell >it looks like the values that would be changed by a change in length >are ignored or overwritten by the hardware and driver anyway. > >- Alex
On Thu, Apr 28, 2016 at 2:43 PM, Matthew Finlay <Matt@mellanox.com> wrote: > > > > > > On 4/20/16, 11:06 AM, "Alexander Duyck" <alexander.duyck@gmail.com> wrote: > >>On Wed, Apr 20, 2016 at 10:40 AM, Saeed Mahameed >><saeedm@dev.mellanox.co.il> wrote: >>> On Tue, Apr 19, 2016 at 10:06 PM, Alexander Duyck <aduyck@mirantis.com> wrote: >>>> This patch assumes that the mlx5 hardware will ignore existing IPv4/v6 >>>> header fields for length and checksum as well as the length and checksum >>>> fields for outer UDP headers. >>>> >>>> I have no means of testing this as I do not have any mlx5 hardware but >>>> thought I would submit it as an RFC to see if anyone out there wants to >>>> test this and see if this does in fact enable this functionality allowing >>>> us to to segment UDP tunneled frames that have an outer checksum. >>>> >>>> Signed-off-by: Alexander Duyck <aduyck@mirantis.com> >>>> --- >>>> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 7 ++++++- >>>> 1 file changed, 6 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c >>>> index e0adb604f461..57d8da796d50 100644 >>>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c >>>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c >>>> @@ -2390,13 +2390,18 @@ static void mlx5e_build_netdev(struct net_device *netdev) >>>> netdev->hw_features |= NETIF_F_HW_VLAN_CTAG_FILTER; >>>> >>>> if (mlx5e_vxlan_allowed(mdev)) { >>>> - netdev->hw_features |= NETIF_F_GSO_UDP_TUNNEL; >>>> + netdev->hw_features |= NETIF_F_GSO_UDP_TUNNEL | >>>> + NETIF_F_GSO_UDP_TUNNEL_CSUM | >>>> + NETIF_F_GSO_PARTIAL; >>>> netdev->hw_enc_features |= NETIF_F_IP_CSUM; >>>> netdev->hw_enc_features |= NETIF_F_RXCSUM; >>>> netdev->hw_enc_features |= NETIF_F_TSO; >>>> netdev->hw_enc_features |= NETIF_F_TSO6; >>>> netdev->hw_enc_features |= NETIF_F_RXHASH; >>>> netdev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL; >>>> + netdev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL_CSUM | >>>> + NETIF_F_GSO_PARTIAL; >>>> + netdev->gso_partial_features = NETIF_F_GSO_UDP_TUNNEL_CSUM; >>>> } >>>> >>>> netdev->features = netdev->hw_features; >>>> >>> >>> Hi Alex, >>> >>> Adding Matt, VxLAN feature owner from Mellanox, >>> Matt please correct me if am wrong, but We already tested GSO VxLAN >>> and we saw the TCP/IP checksum offloads for both inner and outer >>> headers handled by the hardware. >>> >>> And looking at mlx5e_sq_xmit: >>> >>> if (likely(skb->ip_summed == CHECKSUM_PARTIAL)) { >>> eseg->cs_flags = MLX5_ETH_WQE_L3_CSUM; >>> if (skb->encapsulation) { >>> eseg->cs_flags |= MLX5_ETH_WQE_L3_INNER_CSUM | >>> MLX5_ETH_WQE_L4_INNER_CSUM; >>> sq->stats.csum_offload_inner++; >>> } else { >>> eseg->cs_flags |= MLX5_ETH_WQE_L4_CSUM; >>> } >>> >>> We enable inner/outer hardware checksumming unconditionally without >>> looking at the features Alex is suggesting in this patch, >>> Alex, can you elaborate more on the meaning of those features ? and >>> why would it work for us without declaring them ? >> >>Well right now the feature list exposed by the device indicates that >>TSO is not used if a VxLAN tunnel has a checksum in an outer header. >>Since that is not exposed currently that is completely offloaded in >>software via GSO. > > 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. - Alex
>> >> 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. > >- Alex
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
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
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
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c index e0adb604f461..57d8da796d50 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c @@ -2390,13 +2390,18 @@ static void mlx5e_build_netdev(struct net_device *netdev) netdev->hw_features |= NETIF_F_HW_VLAN_CTAG_FILTER; if (mlx5e_vxlan_allowed(mdev)) { - netdev->hw_features |= NETIF_F_GSO_UDP_TUNNEL; + netdev->hw_features |= NETIF_F_GSO_UDP_TUNNEL | + NETIF_F_GSO_UDP_TUNNEL_CSUM | + NETIF_F_GSO_PARTIAL; netdev->hw_enc_features |= NETIF_F_IP_CSUM; netdev->hw_enc_features |= NETIF_F_RXCSUM; netdev->hw_enc_features |= NETIF_F_TSO; netdev->hw_enc_features |= NETIF_F_TSO6; netdev->hw_enc_features |= NETIF_F_RXHASH; netdev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL; + netdev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL_CSUM | + NETIF_F_GSO_PARTIAL; + netdev->gso_partial_features = NETIF_F_GSO_UDP_TUNNEL_CSUM; } netdev->features = netdev->hw_features;
This patch assumes that the mlx5 hardware will ignore existing IPv4/v6 header fields for length and checksum as well as the length and checksum fields for outer UDP headers. I have no means of testing this as I do not have any mlx5 hardware but thought I would submit it as an RFC to see if anyone out there wants to test this and see if this does in fact enable this functionality allowing us to to segment UDP tunneled frames that have an outer checksum. Signed-off-by: Alexander Duyck <aduyck@mirantis.com> --- drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)