Bug#729567: fixed in 3.10.27
I can confirm that with the 3.10.27 linux kernel version there is a
solution (not a real fix as far as I can see) for this problem so that
gro can be left on and connections that get forwarded through an OpenVPN
link keep on working at the normal speed.
Relevant parts of the changelog included below:
commit 1e42fa04afb0dae65292683a5dcad85572ab7553
Author: Simon Horman <horms@verge.net.au>
net: Loosen constraints for recalculating checksum in skb_segment()
[ Upstream commit 1cdbcb7957cf9e5f841dbcde9b38fd18a804208b ]
This is a generic solution to resolve a specific problem that I have observed.
If the encapsulation of an skb changes then ability to offload checksums
may also change. In particular it may be necessary to perform checksumming
in software.
An example of such a case is where a non-GRE packet is received but
is to be encapsulated and transmitted as GRE.
Another example relates to my proposed support for for packets
that are non-MPLS when received but MPLS when transmitted.
The cost of this change is that the value of the csum variable may be
checked when it previously was not. In the case where the csum variable is
true this is pure overhead. In the case where the csum variable is false it
leads to software checksumming, which I believe also leads to correct
checksums in transmitted packets for the cases described above.
Paul
Reply to: