I made an issue in systemd upstream. Luckily the issue has been fixed, and
it will arrive in the next systemd release.

https://github.com/systemd/systemd/issues/5334

On 14 Feb 2017 12:32 a.m., "Jay Vosburgh" <jay.vosbu...@canonical.com>
wrote:

> 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/50725d10e3417fd357abe1df2f177b
> 8458027ac7
>
>         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&#174; Ethernet, visit 
http://communities.intel.com/community/wired

Reply via email to