<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">After some further testing i see that this is not igb specific! Also bond interfaces and e1000e have tso disabled like this:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default"><font face="verdana, sans-serif">tx-tcp-segmentation: off</font><br></div><div class="gmail_default"><font face="verdana, sans-serif">tx-tcp-mangleid-segmentation: off [requested on]</font></div><div class="gmail_default"><font face="verdana, sans-serif"><br></font></div><div class="gmail_default"><font face="verdana, sans-serif">bonded vlan interfaces however have tso enabled, but again vlan interfaces seems to have everything enabled.</font></div><div class="gmail_default"><font face="verdana, sans-serif"><br></font></div><div class="gmail_default"><font face="verdana, sans-serif">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.</font></div><div class="gmail_default"><font face="verdana, sans-serif"><br></font></div><div class="gmail_default"><font face="verdana, sans-serif">Regards,</font></div><div class="gmail_default"><font face="verdana, sans-serif">Hans-Kristian</font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 13 February 2017 at 17:54, Hans-Kristian Bakke <span dir="ltr"><<a href="mailto:hkbakke@gmail.com" target="_blank">hkbakke@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">In a previous thread on this mailing list (Excessive throttling with fq) it was concluded that the reason for the bad performance was that tso was somewhat inconcistent between the bond and the physical interfaces. I never really knew why, but I knew I had been experimenting with traffic shaping and offloads so I naturally thought that was the culprit.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">However, I have now rebooted some of my systems and in both of my Debian Stretch (testing) systems (I tried both kernel 4.8 and 4.9, one with fq_codel and one with sch_fq) I end up with this combination of segmentation offload settings:</div><div class="gmail_default"><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">...</div><div class="gmail_default" style="font-family:verdana,sans-serif">tcp-segmentation-offload: on</div><div class="gmail_default" style="font-family:verdana,sans-serif"> tx-tcp-segmentation: off <---- ???</div><div class="gmail_default" style="font-family:verdana,sans-serif"> tx-tcp-ecn-segmentation: off [fixed]</div><div class="gmail_default" style="font-family:verdana,sans-serif"> tx-tcp-mangleid-segmentation: off</div><div class="gmail_default" style="font-family:verdana,sans-serif"> tx-tcp6-segmentation: on</div><div class="gmail_default" style="font-family:verdana,sans-serif">udp-fragmentation-offload: off [fixed]</div><div class="gmail_default" style="font-family:verdana,sans-serif">generic-segmentation-offload: on</div><div class="gmail_default" style="font-family:verdana,sans-serif">...</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">If I do the following...<br></div><div><font face="verdana, sans-serif">ethtool -K eth0 tx-tcp-segmentation on </font><br></div><div><font face="verdana, sans-serif"><br></font></div><div><font face="verdana, sans-serif">...I end up with what I expect and the performance returns for sch_fq with pacing.</font></div><div><font face="verdana, sans-serif"><div>...</div><div>tcp-segmentation-offload: on</div><div> tx-tcp-segmentation: on</div><div> tx-tcp-ecn-segmentation: off [fixed]</div><div> tx-tcp-mangleid-segmentation: off</div><div> tx-tcp6-segmentation: on</div><div>udp-fragmentation-offload: off [fixed]</div><div>generic-segmentation-offload: on</div><div>...</div><div><br></div><div>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)<br></div><div><br></div><div>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.</div><div><div><br></div><div># Proxmox VE system (full TSO by default)</div><div><div>#ethtool -i eth1</div><div>driver: igb</div><div>version: 5.3.5.3</div><div>firmware-version: 3.19, 0x00013cbf</div><div>bus-info: 0000:03:00.1</div><div>supports-statistics: yes</div><div>supports-test: yes</div><div>supports-eeprom-access: yes</div><div>supports-register-dump: yes</div><div>supports-priv-flags: no</div></div></div><div><br></div><div># Debian Stretch systems (half-enabled TSO by default)</div><div><div># ethtool -i eth2</div><div>driver: igb</div><div>version: 5.4.0-k</div><div>firmware-version: 0.0.0</div><div>expansion-rom-version:</div><div>bus-info: 0000:00:14.2</div><div>supports-statistics: yes</div><div>supports-test: yes</div><div>supports-eeprom-access: yes</div><div>supports-register-dump: yes</div><div>supports-priv-flags: no</div></div><div><br></div><div>The NIC that the "working" and the "non-working" system have is HP NC365T, which is based on intel 82580. <br></div><div>The other "non-working" Debian Stretch system is a Intel Rangeley Atom c2758 supermicros system with a quad intel I354 network controller embedded.</div><div><br></div><div>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)<br></div><div><br></div><div>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.</div><div><br></div><div>So to my questions:</div><div>- Can anyone think of a reason why tx-tcp-segmentation offload is disabled by default (and not tcp segmentation offload in general)</div><div>- Do you have any tips to troubleshoot this?</div><div>- As this default combination of out-of-the-box settings is bad for fq with pacing performance, and it seems to somewhat be the default now for two different igb-systems I thought I should give you a heads up.</div><div><br></div><div>Regards,</div><div>Hans-Kristian</div></font></div></div></div>
</blockquote></div><br></div>