Date: Sat, 27 Mar 2021 03:57:31 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 254596] if_bridge wants LRO turned off, if_vlan insists it remain on Message-ID: <bug-254596-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254596 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@FreeBSD.org Reporter: paul@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 |=3D p->if_capabilities & IFCAP_LRO; if (p->if_capenable & IFCAP_VLAN_HWCSUM) ena |=3D p->if_capenable & IFCAP_LRO; to get LRO to not be sticky-on for a vlan subinterface, i would have to rem= ove LRO from the parent interface. i don't think this is functioning as intende= d, 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-254596-227>