Your message dated Wed, 18 Feb 2015 12:54:23 +0000
with message-id <1424264063.23608.83.ca...@decadent.org.uk>
and subject line Re: Bug#778239: Strange GRE packet forwarding slowness in
3.16.7-ckt2-1~bpo70+1
has caused the Debian Bug report #778239,
regarding Strange GRE packet forwarding slowness in 3.16.7-ckt2-1~bpo70+1
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
778239: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778239
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:linux
Version: 3.16.7-ckt2-1~bpo70+1
Severity: normal
Hi!
I have encountered a strange slowness on a router/packetfilter system
(Wheezy 7.8 with backported kernel 3.16.7-ckt2-1~bpo70+1) of mine while
forwarding GRE packets.
The system in question does not terminate the GRE tunnels itself, it
merely forwards those packets from one interface to another.
This problem occurred after a reboot from a 3.12-bpo to the current
3.16.7-ckt2-1~bpo70+1.
This problem reminded me of
http://lists.openwall.net/netdev/2014/07/08/132 and
http://patchwork.ozlabs.org/patch/324953/ and as described on those
mailing-list exchanges, after disabling GSO and GRO on the involved
interfaces, the forwarding speed for GRE packets was back to normal.
What puzzles me is the fact that this bug should be fixed since 3.14.x
and 3.15.x and sure enough, I can find the code changes from the patch
from patchwork in the current kernel code in the Debian package.
But the symptoms are the same as described: with active GRO/GSO the GRE
tunnels max out at about 200kbit/s, after disabling GRO/GSO the possible
bandwidth is only limited by the speed of the interfaces and connections
involved.
The hardware is like this:
14:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit
SFI/SFP+ Network Connection (rev 01)
14:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit
SFI/SFP+ Network Connection (rev 01)
0e:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit
SFI/SFP+ Network Connection (rev 01)
0e:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit
SFI/SFP+ Network Connection (rev 01)
ixgbe 0000:14:00.0: Multiqueue Enabled: Rx Queue count = 16, Tx Queue
count = 16
ixgbe 0000:14:00.0: PCI Express bandwidth of 32GT/s available
ixgbe 0000:14:00.0: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%)
ixgbe 0000:14:00.0: MAC: 2, PHY: 14, SFP+: 5, PBA No: FFFFFF-0FF
ixgbe 0000:14:00.0: 00:10:f3:33:d3:e8
ixgbe 0000:14:00.0: Intel(R) 10 Gigabit Network Connection
I created two LACP bonds (bond0 and bond1) out of two interfaces and on
top of those two bonds there are several VLANs. The GRE packets are
forwarded from a VLAN on bond0 to a VLAN on bond1.
The regain the full bandwidth I disabled GSO and GRO on each of the four
slave interfaces and both bond interfaces.
Grüße,
Sven.
signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Version: 3.16.7-ckt4-3
On Wed, 2015-02-18 at 10:46 +0100, Sven Hartge wrote:
> On 18.02.2015 09:17, Sven Hartge wrote:
> > On 18.02.2015 02:25, Ben Hutchings wrote:
> >> On Wed, 2015-02-18 at 00:14 +0100, Sven Hartge wrote:
> >>> On Thu, 12 Feb 2015 16:33:09 +0100 Sven Hartge <s...@svenhartge.de> wrote:
>
> >>>> I have encountered a strange slowness on a router/packetfilter system
> >>>> (Wheezy 7.8 with backported kernel 3.16.7-ckt2-1~bpo70+1) of mine while
> >>>> forwarding GRE packets.
> >>>
> >>> Could this be the fix for this bug:
> >>>
> >>> https://lists.ubuntu.com/archives/kernel-team/2014-December/052158.html
> >>>
> >>> "gre: Set inner mac header in gro complete"
> >>
> >> I don't know.
> >>
> >>> I cannot confirm this myself right now, as the only systems affected are
> >>> in production and I am not able to set up a lab installation right now.
> >>
> >> As that went into 3.16.7-ckt3, it is therefore included in the current
> >> packages in testing/unstable.
> >
> > Well, I've got a window for testing later today. I will report back, if
> > this release fixes the problem I am seeing.
>
> Yes, this patch fixes this problem for me. Should I close the bug or do
> you want to do it?
I'm closing it.
Ben.
--
Ben Hutchings
To err is human; to really foul things up requires a computer.
signature.asc
Description: This is a digitally signed message part
--- End Message ---
