On Fri, Mar 18, 2016 at 6:42 PM, Ben Hutchings <b...@decadent.org.uk> wrote: > On Fri, 2016-03-18 at 17:30 -0700, Alexander Duyck wrote: >> On Fri, Mar 18, 2016 at 5:18 PM, Ben Hutchings <b...@decadent.org.uk> wrote: >> > On Fri, 2016-03-18 at 16:25 -0700, Alexander Duyck wrote: >> > > [NETIF_F_GSO_IPIP_BIT] = "tx-ipip-segmentation", >> > > [NETIF_F_GSO_SIT_BIT] = "tx-sit-segmentation", >> > > [NETIF_F_GSO_UDP_TUNNEL_BIT] = "tx-udp_tnl-segmentation", >> > > + [NETIF_F_GSO_UDP_TUNNEL_CSUM_BIT] = "tx-udp_tnl-csum-segmentation", >> > > + [NETIF_F_GSO_TUNNEL_REMCSUM_BIT] = "tx-remcsum-segmentation", >> > I think this should be "tx-tunnel-remote-checksum-segmentation", though >> > that is getting quite unwieldy. >> Right. As it is I think we might be coming up on the 32 character >> limit for the strings. Replacing csum with checksum would probably >> push us over. > > Right, I wasn't even thinking about the static limit! That does weigh > rather heavily in favour of abbreviation here. > > Please do at least hyphenate "remcsum" though.
I think that remote checksum offload is just a purely internal feature - that is no device will ever expose support for it, since it is explicitly to work around lack of hardware support. As a result, I don't know if it makes sense to show it through ethtool at all.