Page MenuHomeFreeBSD

bridge: Further decompose GRAB_OUR_PACKETS
Needs ReviewPublic

Authored by markj on Feb 7 2023, 7:24 PM.
Tags
None
Referenced Files
F102836308: D38425.diff
Sun, Nov 17, 7:33 PM
Unknown Object (File)
Tue, Oct 29, 9:19 PM
Unknown Object (File)
Oct 16 2024, 1:06 PM
Unknown Object (File)
Oct 16 2024, 12:59 PM
Unknown Object (File)
Sep 26 2024, 9:05 PM
Unknown Object (File)
Sep 20 2024, 2:13 PM
Unknown Object (File)
Sep 17 2024, 9:26 PM
Unknown Object (File)
Sep 7 2024, 4:20 PM
Subscribers

Details

Reviewers
melifaro
kp
Group Reviewers
network
Summary

Introduce an inline function which consumes a packet known to be
destined for a particular interface. Generally, avoid introducing
macros with side effects.

Add a bridge_learn() helper instead of having the same code duplicated
into the local and forwarding cases.

Simplify some conditionals in bridge_forward().

No functional change intended.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 49612
Build 46502: arc lint + arc unit

Event Timeline

markj requested review of this revision.Feb 7 2023, 7:24 PM
sys/net/if_bridge.c
2636

One small benefit of this approach is that we don't need to test the bridge interface type. There might be some other simplifications that are possible.

zlei added inline comments.
sys/net/if_bridge.c
2646

I wonder if we can have a hash map lladdr -> ifp to speed up lookups for bridge which have large quantity members.

I'm not really looking at if_bridge anymore, so I'll drop this patch. If anyone wants to take it and change/improve it, please feel free.

sys/net/if_bridge.c
2646

Yes, that's probably a good idea. Even a flat array would be better than the linked list; now that the data path is protected by an epoch section, it should be pretty easy to implement resizing.