On 05/18/2018 06:24 AM, Mikhail Sennikovsky wrote: > Hi all, > > We were recently experiencing network performance issues with VLAN > networking setup with Open vSwitch, for the ingress traffic coming to > VLAN trunk port of the ovs. > As we discovered, the issue was caused by gro not working for it, > which in turn was because the gro receive callbacks for 802.1Q payload > type are defined in the 8021q module (see > https://elixir.bootlin.com/linux/v4.16.9/source/net/8021q/vlan.c#L762 > ), which was not loaded. > This resulted in a significant bandwidth performance drop, having > ~3Gbps instead of the expected ~7Gbps for a simple iperf3 test in our > case. > > The obvious work-around would be to load the 8021q module, which > indeed makes bandwidth performance back to the expected numbers. > This seems like a hidden and not obvious magic however. > > So I'm questioning, whether it makes sense to have the gro receive > callbacks for 802.1Q and 802.1ad moved to some common place, that > would be used/enabled by both 8021q and openvswitch modules.
Sure, GRO should do whatever it can. TCP IPv6 traffic can be aggregated by GRO even if IPv6 module is not loaded. net/ipv6/Makefile : ipv6-offload := ip6_offload.o tcpv6_offload.o exthdrs_offload.o ... obj-$(CONFIG_INET) += output_core.o protocol.o $(ipv6-offload)
