Brandeburg, Jesse <jesse.brandeb...@intel.com> wrote:
>You've seem to have found a major regression, if you wouldn't mind
>would you post the bug to debian Bugzilla and let us know the number so
>we can watch/join in?
>
>Breaking stateless offloads like this will knock everyone down to sub
>10Gb performance, and increase CPU dramatically for no reason.
From poking around a bit, it could be to be due to the systemd
commit:
commit 50725d10e3417fd357abe1df2f177b8458027ac7
Author: Susant Sahani <ssah...@users.noreply.github.com>
Date: Tue Aug 30 20:22:04 2016 +0530
link : add support to configure Offload features (#4017)
This patch supports these features to be on or off
Generic Segmentation Offload
TCP Segmentation Offload
UDP Segmentation Offload
fixes #432
https://github.com/systemd/systemd/commit/50725d10e3417fd357abe1df2f177b8458027ac7
Note from the commit that the default appears to be "off":
+ <term><varname>TCPSegmentationOffload=</varname></term>
+ <listitem>
+ <para>The TCP Segmentation Offload (TSO) when true enables
+ TCP segmentation offload. Takes a boolean value.
+ Defaults to "unset".</para>
Perhaps there is a backwards compatibility issue with the new
systemd vs. an old configuration that does not enable these.
-J
>Thanks!
>
>-----Original Message-----
>From: Hans-Kristian Bakke [mailto:hkba...@gmail.com]
>Sent: Monday, February 13, 2017 9:53 AM
>To: e1000-devel@lists.sourceforge.net
>Subject: Re: [E1000-devel] Why is tx-tcp-segmentation set to off for igb by
>default?
>
>Yep.. downgrading systemd from 232.15 to 231.10 fixed it.
>
>There you have it. Systemd 232 not only got the ability to set offloads,
>but it also disables tx-tcp-segmentation by default for both physical NICs
>and bonds.
>
>These packages from Debian Snapshots did the trick:
>libsystemd0_231-10_amd64.deb
>libudev1_231-10_amd64.deb
>systemd_231-10_amd64.deb
>udev_231-10_amd64.deb
>
>This is ...fun.... No wonder file my server performance got more unreliable
>the last couple of months.
>
>On 13 February 2017 at 18:39, Hans-Kristian Bakke <hkba...@gmail.com> wrote:
>
>> After some further testing i see that this is not igb specific! Also bond
>> interfaces and e1000e have tso disabled like this:
>>
>> tx-tcp-segmentation: off
>> tx-tcp-mangleid-segmentation: off [requested on]
>>
>> bonded vlan interfaces however have tso enabled, but again vlan interfaces
>> seems to have everything enabled.
>>
>> As downgrading the kernel to a known good did not do the trick there must
>> be something else systemwide in Debian Stretch. Perhaps I should really try
>> to get all the dependencies together to downgrade systemd.
>>
>> Regards,
>> Hans-Kristian
>>
>> On 13 February 2017 at 18:05, Hans-Kristian Bakke <hkba...@gmail.com>
>> wrote:
>>
>>> While testing sch_fq with BBR i noticed that my igb-driver NICs have
>>> tx-tcp-segmentation set to off in both my Debian Stretch (Testing) systems
>>> by default (I tried both kernel 4.8 and 4.9, one with fq_codel and one
>>> with sch_fq). More specifically I end up with this combination of
>>> segmentation offload settings (from ethtool):
>>>
>>> ...
>>> tcp-segmentation-offload: on
>>> tx-tcp-segmentation: off <---- ???
>>> tx-tcp-ecn-segmentation: off [fixed]
>>> tx-tcp-mangleid-segmentation: off
>>> tx-tcp6-segmentation: on
>>> udp-fragmentation-offload: off [fixed]
>>> generic-segmentation-offload: on
>>> ...
>>>
>>> If I do the following...
>>> ethtool -K eth0 tx-tcp-segmentation on
>>>
>>> ...I end up with what I expect and the performance returns for sch_fq
>>> with pacing.
>>> ...
>>> tcp-segmentation-offload: on
>>> tx-tcp-segmentation: on
>>> tx-tcp-ecn-segmentation: off [fixed]
>>> tx-tcp-mangleid-segmentation: off
>>> tx-tcp6-segmentation: on
>>> udp-fragmentation-offload: off [fixed]
>>> generic-segmentation-offload: on
>>> ...
>>>
>>> I have some other Debian Jessie systems also using the igb-driver and tso
>>> is always enabled here by default (but not the same NIC). (Kernel 3.16)
>>>
>>> I also have a Proxmox VE system on kernel 4.4 with exactly the same quad
>>> NIC that i suspect do not use the kernel source igb-drivers as it has a lot
>>> more params that also has tso enabled correctly.
>>>
>>> # Proxmox VE system (full TSO by default)
>>> #ethtool -i eth1
>>> driver: igb
>>> version: 5.3.5.3
>>> firmware-version: 3.19, 0x00013cbf
>>> bus-info: 0000:03:00.1
>>> supports-statistics: yes
>>> supports-test: yes
>>> supports-eeprom-access: yes
>>> supports-register-dump: yes
>>> supports-priv-flags: no
>>>
>>> # Debian Stretch systems (half-enabled TSO by default)
>>> # ethtool -i eth2
>>> driver: igb
>>> version: 5.4.0-k
>>> firmware-version: 0.0.0
>>> expansion-rom-version:
>>> bus-info: 0000:00:14.2
>>> supports-statistics: yes
>>> supports-test: yes
>>> supports-eeprom-access: yes
>>> supports-register-dump: yes
>>> supports-priv-flags: no
>>>
>>> The NIC that the "working" and the "non-working" system have is HP
>>> NC365T, which is based on intel 82580.
>>> The other "non-working" Debian Stretch system is a Intel Rangeley Atom
>>> c2758 supermicros system with a quad intel I354 network controller embedded.
>>>
>>> I tried booting the stretch system with kernel 3.16 from Debian Jessie to
>>> get the same drivers like my working systems but no change. Then I noticed
>>> that systemd got the ability to change exactly these offloads in the last
>>> systemd version 232 which arrived in testing in the end of 2016 so I am
>>> thinking that this might have something to do with this, but I have not
>>> found anything (mostly because I don't even really know where to look)
>>>
>>> I also tried to not having one of the interfaces in any kind of bond or
>>> vlan subinterface in case those were changing some stuff but no changes in
>>> behaviour.
>>>
>>> So to my questions:
>>> - Can anyone think of a reason why tx-tcp-segmentation offload is
>>> disabled by default?
>>> - Do you have any tips to troubleshoot this?
>>>
>>> Regards,
>>> Hans-Kristian
---
-Jay Vosburgh, jay.vosbu...@canonical.com
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit
http://communities.intel.com/community/wired
