|
Hello,
On Tue, 11 Dec 2012, Thomas Bätzler wrote:
> Hi
>
> Zhongkang Lao wrote on 05.12.2012 08:41:
> > I have already googled this like a hundred of times, but I got nothing.
> > I didn't find any page or any article explain this.
> > I'm sure someone here can explain this.
> > So sorry to bother you guys here.
>
> I don't have any answers, but I can confirm the problem (and the
> workaround) on a box running Debian "Squeeze" with 2.6.32 directing
> traffic from a VIP bound to lo via NAT to an active/backup bonding
> interface on the backend. With "gro on" for the bonded interfaces to the
> backend real servers, throughput was ~64K/s. With "gro off" it was
> ~50MB/s. It's not a general networking problem since a direct connection
> to the real server via a DNAT port forward was not impacted.
>
> >From what I gleaned from a cursory look with tcpdump it seems that the
> problem is caused by incorrectly calculated tcp checksums.
>
> Anybody interested in pursuing this further?
It is fixed in mainline more than 2 years ago:
===
commit 8f1b03a4c18e8f3f0801447b62330faa8ed3bb37
Author: Simon Horman <horms@xxxxxxxxxxxx>
Date: Tue Nov 9 10:08:49 2010 +0900
ipvs: allow transmit of GRO aggregated skbs
Attempt at allowing LVS to transmit skbs of greater than MTU length that
have been aggregated by GRO and can thus be deaggregated by GSO.
===
Without this fix IPVS assumes that large packets
are received and sends FRAG_NEEDED messages. For old
kernels GRO should be disabled to avoid the problem.
> Cheers,
> Thomas
Regards
--
Julian Anastasov <ja@xxxxxx>_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
