On Mon, May 2, 2016 at 9:48 AM, Alexander Duyck <[email protected]> wrote: > On Mon, May 2, 2016 at 9:33 AM, Tom Herbert <[email protected]> wrote: >> On Mon, May 2, 2016 at 9:25 AM, Alexander Duyck <[email protected]> wrote: >>> In the case of the mlx4 and mlx5 driver they do not support IPv6 checksum >>> offload for tunnels. With this being the case we should disable GSO in >>> addition to the checksum offload features when we find that a device cannot >>> perform a checksum on a given packet type. >>> >> I'm not sure I understand this. If device can't support checksum >> offload for tunnels doesn't that mean we have to do the checksum on >> host regardless of whether GSO is being done? > > The use of the term GSO here might be the confusing part. Basically > the issue is the hardware advertises it can do TSO for IPv4 on > encapsulated frames, however it doesn't indicate it can do IPv6 > checksum offload. So what ends up happening is that in the case of a > v4 over v6 tunnel we were going through validate_xmit_skb which will > check things in netif_skb_features and come out supporting the TSO but > no checksums. As a result we would fall through and hit > skb_checksum_help and trigger the warn on in there because we had TSO > requested even though we couldn't do the checksum. > > Basically I am just extending the kind of logic we have in > netdev_fix_features so that if we cannot support checksumming the > frame then we cannot support segmenting it. > Thanks for the explanation. We need to drive things so that all the encapsulation combinations (v4/v4, v4/v6, v6/v4, v6/v6) are supported by HW TSO if any of them are supported by a device. Maybe we should still have some sort of warning message that HW is broken for some combination (like it apparently it is for mlnx4)?
Tom > - Alex
