[Bug 254596] if_bridge wants LRO turned off, if_vlan insists it remain on

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sat Mar 27 03:57:31 UTC 2021


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254596

            Bug ID: 254596
           Summary: if_bridge wants LRO turned off, if_vlan insists it
                    remain on
           Product: Base System
           Version: 12.2-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: paul at redbarn.org

today i added a vlan subinterface to a bridge, and dmesg reported:

bridge1: can't disable some capabilities on igb0.203: 0x400

this is IFCAP_LRO. bridge(4) says:

"on all interfaces added to the bridge ... The LRO capability is always
disabled."

wikipedia(Large receive offload) says:

"LRO should not operate on machines acting as routers, as it breaks the
end-to-end principle and can significantly impact performance."

sys/net/if_vlan.c says:

        /*
         * If the parent interface can do LRO and checksum offloading on
         * VLANs, then guess it may do LRO on VLANs.  False positive here
         * cost nothing, while false negative may lead to some confusions.
         */
        if (p->if_capabilities & IFCAP_VLAN_HWCSUM)
                cap |= p->if_capabilities & IFCAP_LRO;
        if (p->if_capenable & IFCAP_VLAN_HWCSUM)
                ena |= p->if_capenable & IFCAP_LRO;

to get LRO to not be sticky-on for a vlan subinterface, i would have to remove
LRO from the parent interface. i don't think this is functioning as intended,
because i have other non-bridged subinterfaces for which LRO is appropriate.

i am not posting a candidate fix because too many layers are being crossed here
and there's not an obvious way to relax this deep constraint. someone with
recent kernel architecture chops should take a look.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list