Page MenuHomeFreeBSD

if_bridge: Mask MEXTPG if some members don't support it
ClosedPublic

Authored by markj on Sat, Oct 26, 6:36 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 7, 12:48 AM
Unknown Object (File)
Fri, Nov 1, 12:20 PM
Unknown Object (File)
Fri, Nov 1, 12:20 PM
Unknown Object (File)
Fri, Nov 1, 12:20 PM
Unknown Object (File)
Fri, Nov 1, 12:15 PM
Unknown Object (File)
Tue, Oct 29, 5:07 PM
Unknown Object (File)
Sat, Oct 26, 8:04 PM

Details

Summary

Similar to how the network stack needs to use mb_unmapped_to_ext()
to convert mbufs before passing them to an unsupported driver, if_bridge
needs to avoid passing M_EXTPG mbufs to interfaces. Thus, clear
IFCAP_MEXTPG if any member interfaces don't handle unmapped mbufs.

PR: 278245
MFC after: 2 weeks

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj requested review of this revision.Sat, Oct 26, 6:36 PM
This revision is now accepted and ready to land.Mon, Oct 28, 1:41 PM

Why do we want or need a hardcoded list? Why can't this function be more like lagg_capabilities()? If we do want a hardcoded list, what about IFCAP_TXTLS*

Why do we want or need a hardcoded list? Why can't this function be more like lagg_capabilities()? If we do want a hardcoded list, what about IFCAP_TXTLS*

That's a good question. if_bridge could probably be smarter, indeed.

Why exactly does if_bridge need to care about IFCAP_TXTLS*?

Why do we want or need a hardcoded list? Why can't this function be more like lagg_capabilities()? If we do want a hardcoded list, what about IFCAP_TXTLS*

That's a good question. if_bridge could probably be smarter, indeed.

Why exactly does if_bridge need to care about IFCAP_TXTLS*?

The same reason lagg does.... if its enabled (along with MEXTPG) and the bridge interface is used as an egress interface, we'll at the very least attempt to alloc a send tag.. I'm not 100% certain it would be a problem, but it seems more obvious to mask the feature off