pfSense

It looks like there's a disconnect between the sysctl tunable and whether the Hardware TCP Segmentation Offloading box is checked or unchecked in the graphical interface. As Marcos pointed out, the defaults are net.inet.tcp.tso=1 and System > Advanced > Networking: Hardware TCP Segmentation Offloading is checked. One control indicates TSO is enabled, the other says it's disabled. Specifically:

[2.6.0-RELEASE][root@pfSense.home.arpa]/root: ifconfig -vvm vtnet0
vtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=800b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE>
    capabilities=7d07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,NETMAP,RXCSUM_IPV6,TXCSUM_IPV6>

[2.6.0-RELEASE][root@pfSense.home.arpa]/root: sysctl net.inet.tcp.tso
net.inet.tcp.tso: 1

Unchecking Hardware TCP Segmentation Offloading in the graphical interface (thereby enabling TSO4, TSO6) and rebooting, shows the result below. Still net.inet.tcp.tso=1 (untouched from default) and the result is what we would expect (1 in this case is On/Enabled and 0 is Off/Disabled). Both controls are in agreement.

[2.6.0-RELEASE][root@pfSense.home.arpa]/root: ifconfig -vvm vtnet0
vtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=c03b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO,LINKSTATE>
    capabilities=7d07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,NETMAP,RXCSUM_IPV6,TXCSUM_IPV6>

[2.6.0-RELEASE][root@pfSense.home.arpa]/root: sysctl net.inet.tcp.tso
net.inet.tcp.tso: 1

Below is after changing net.inet.tcp.tso to 0 and rebooting. System > Advanced > Networking: Hardware TCP Segmentation Offloading is still checked (TSO disabled). Both commands report that TSO is off, which is what we'd expect. Both controls are in agreement.

[2.6.0-RELEASE][root@pfSense.home.arpa]/root: sysctl net.inet.tcp.tso
net.inet.tcp.tso: 0

[2.6.0-RELEASE][root@pfSense.home.arpa]/root: ifconfig -vvm vtnet0
vtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=800b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE>
    capabilities=7d07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,NETMAP,RXCSUM_IPV6,TXCSUM_IPV6>

Now net.inet.tcp.tso is still unchanged from 0, but System > Advanced > Networking: Hardware TCP Segmentation Offloading is unchecked. The sysctl value still shows off, but the GUI and interface report TSO is enabled. Now the two controls are in disagreement again.

[2.6.0-RELEASE][root@pfSense.home.arpa]/root: sysctl net.inet.tcp.tso
net.inet.tcp.tso: 0

[2.6.0-RELEASE][root@pfSense.home.arpa]/root: ifconfig -vvm vtnet0
vtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=c03b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO,LINKSTATE>
    capabilities=7d07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,NETMAP,RXCSUM_IPV6,TXCSUM_IPV6>

I reset my VM, immediately changed the tunable to 0, unchecked the Hardware TSO checkbox, and let it reboot. The result was again disagreement.

The two settings are not tied together so that's all normal and expected.

The value on the individual network interfaces is basically "does this interface want to use TSO?" and it can be yes/no for 4/6 individually

The sysctl value is a global toggle that turns it off for the entire system.

It's entirely possible and logical for the global value to be off but the NICs to still say they want to use TSO and vice versa.

I think trying to tie these together is going to be more trouble than it's worth. We already manage the NIC settings as needed, it doesn't seem like we need to fuss with the sysctl. If someone really cares that much about them matching they can set the sysctl themselves as a tunable.

It seems to me that the intention for the checkbox is to behave as a global toggle.

But it's much more confusing for users to see the flag on the interfaces when it may not actually be active than it is to see the sysctl value be 1 instead of 0. Few people even know the sysctl exists, lots of people may look at ifconfig for various reasons.

I still haven't seen a compelling case for toggling the sysctl other than the fact that it exists. Is there some case not covered by the current behavior that the sysctl helps with? If so, how many users does that actually affect?

Indeed it affects few users. I personally haven't seen it do anything, and it's only served to confuse troubleshooting. Perhaps the better thing to do then is to not add it in the first place? Or at least clarify the distinction between the two options to lessen any confusion while troubleshooting. For reference, it was added here: https://github.com/pfsense/pfsense/commit/e2bee3feb119370f431384eee9fb7cd6c91c3937

As with any tunable that's just a default. That was ~12 years ago and before that we disabled it globally because of other problems, now it's per-interface because that's more user friendly. With the tunable defaulting to 1 the GUI options for TSO are able to be toggled by the user, leaving the decision in their hands.

We can't just remove that tunable default because if it is or changes to 0 by default in FreeBSD then the GUI toggle wouldn't work.

So we either would remove it from the tunables list and manage it automatically based on the GUI checkbox or leave it as-is which gives the most flexibility to the user.

It doesn't seem like a great idea to be taking on more technical debt and complexity to fix an issue seen by a very small number of users, that we can't verify internally is even legitimate.