Bug 254596 - if_bridge wants LRO turned off, if_vlan insists it remain on
Summary: if_bridge wants LRO turned off, if_vlan insists it remain on
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.2-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-net (Nobody)
Keywords: needs-patch, needs-qa
Depends on:
Reported: 2021-03-27 03:57 UTC by paul vixie
Modified: 2021-07-31 21:11 UTC (History)
4 users (show)

See Also:
koobs: maintainer-feedback? (melifaro)
koobs: mfc-stable13?
koobs: mfc-stable12?


Note You need to log in before you can comment on or make changes to this bug.
Description paul vixie 2021-03-27 03:57:31 UTC
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.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2021-03-27 04:08:39 UTC
@Alexander Anyone else you suggest might be suitable/able to advise on this issue?