> >> @@ -237,6 +237,7 @@ static inline int find_next_netdev_feature(u64 > >> feature, unsigned long start) > >> NETIF_F_GSO_GRE_CSUM | \ > >> NETIF_F_GSO_IPXIP4 | \ > >> NETIF_F_GSO_IPXIP6 | \ > >> + NETIF_F_GSO_UDP_L4 | \ > >> NETIF_F_GSO_UDP_TUNNEL | \ > >> NETIF_F_GSO_UDP_TUNNEL_CSUM) > > > > Are you adding this to NETIF_F_GSO_ENCAP_ALL? Wouldn't it make more > > sense to add it to NETIF_F_GSO_SOFTWARE? > > > > Yes, I'm adding to NETIF_F_GSO_ENCAP_ALL (not very clear from the > context). I will fix the commit log. > > In: 83aa025 udp: add gso support to virtual devices, the support was > also added to NETIF_F_GSO_ENCAP_ALL (although subsequently reverted due > to UDP GRO not being in place), so I wonder what the reason was for that?
That was probably just a bad choice on my part. It worked in practice, but if NETIF_F_GSO_SOFTWARE works the same without unexpected side effects, then I agree that it is the better choice. That choice does appear to change behavior when sending over tunnel devices. Might it send tunneled GSO packets over loopback? > I agree that NETIF_F_GSO_SOFTWARE seems conceptually more logical and > further I think it adds support for more 'virtual' devices. For example, > I tested loopback with NETIF_F_GSO_UDP_L4 being added to > NETIF_F_GSO_SOFTWARE and it shows a nice performance gain, whereas > NETIF_F_GSO_ENCAP_ALL isn't included for loopback. > > Thanks, > > -Jason
