public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: John Hughes <john@calva•com>
To: Eric Dumazet <eric.dumazet@gmail•com>
Cc: John Hughes <john@atlantech•com>, netdev@vger•kernel.org
Subject: Re: When a TCP segment is split up (to be sent through a TUN device with a small MTU) who should recalculate the checksum?
Date: Fri, 15 Nov 2013 15:02:08 +0100	[thread overview]
Message-ID: <52862960.6090408@calva.com> (raw)
In-Reply-To: <1384520815.28716.63.camel@edumazet-glaptop2.roam.corp.google.com>

On 15/11/13 14:06, Eric Dumazet wrote:
> On Fri, 2013-11-15 at 09:52 +0100, John Hughes wrote:
>> I have two offices, joined by a OpenVPN tunnel.  I've upgraded the
>> kernels in the machines running the tunnel to 3.10.  All of a sudden I'm
>> getting horrible transmission delays between the two offices.
>>
>> office1 LAN--------office1 tunnel machine
>>                               |
>>                               | openvpn tunnel
>>                               |
>>                       office2 tunnel machine------office2 LAN
>>                                     
>>
>> What seems to be happening is that packets are arriving at the LAN
>> interface of the machine running the tunnel and being combined by
>> generic-receive-offload.  These packets then have to be split up again
>> as they are too big for the tunnels MTU.
>>
>> But when the packets are split the TCP checksum doesn't seem to be being
>> recalculated, so the systems on the other end of the tunnel ignore them,
>> forcing many retries and the observed delays.
>>
>>
> Thanks for the report
>
> It depends on the offload capabilities of the NIC forwarding packets

The NIC is a kernel tun device.
>
> ethtool -k eth0

# ethtool -k tun1
Features for tun1:
rx-checksumming: off [fixed]
tx-checksumming: off
	tx-checksum-ipv4: off [fixed]
	tx-checksum-ip-generic: off [requested on]
	tx-checksum-ipv6: off [fixed]
	tx-checksum-fcoe-crc: off [fixed]
	tx-checksum-sctp: off [fixed]
...

It seems someone has asked the tunnel to compute checksums 
(tx-checksum-ip-generic), but it can't do that.


>
> TCP checksums can be recomputed by tcp_gso_segment() (it was named
> tcp_tso_segment() in linux 3.10), unless the NIC told it was doing the
> checksum computation itself.
>
> ethtool -K eth0 tx off
>
> Should request stack to perform the cheksums.
>
> What is the NIC doing the transmits ?
>
>
>

  reply	other threads:[~2013-11-15 14:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-15  8:52 When a TCP segment is split up (to be sent through a TUN device with a small MTU) who should recalculate the checksum? John Hughes
2013-11-15 13:06 ` Eric Dumazet
2013-11-15 14:02   ` John Hughes [this message]
2013-11-15 14:20 ` Vlad Yasevich
2013-11-15 14:31   ` John Hughes
2013-11-15 14:41     ` Vlad Yasevich
2013-11-15 14:55       ` John Hughes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52862960.6090408@calva.com \
    --to=john@calva$(echo .)com \
    --cc=eric.dumazet@gmail$(echo .)com \
    --cc=john@atlantech$(echo .)com \
    --cc=netdev@vger$(echo .)kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox