Page MenuHomeFreeBSD

ip_mroute: Convert to using a regular mutex
ClosedPublic

Authored by markj on Jan 8 2026, 4:44 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 29 2026, 5:00 AM
Unknown Object (File)
Jan 28 2026, 9:41 PM
Unknown Object (File)
Jan 25 2026, 12:24 PM
Unknown Object (File)
Jan 21 2026, 11:24 AM
Unknown Object (File)
Jan 15 2026, 9:31 PM
Unknown Object (File)
Jan 14 2026, 10:20 PM
Unknown Object (File)
Jan 12 2026, 1:08 PM
Unknown Object (File)
Jan 10 2026, 4:51 PM

Details

Summary

The multicast routing code was using spin mutexes for packet counting,
but there is no reason to use them instead of regular mutexes, given
that none of this code runs in an interrupt context. Convert to using
default mutexes.

Diff Detail

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

Event Timeline

markj requested review of this revision.Jan 8 2026, 4:44 PM
This revision is now accepted and ready to land.Jan 8 2026, 5:38 PM
This revision was automatically updated to reflect the committed changes.

Wouldn't atomics be more appropriate for higher PPS yield?

In D54603#1264925, @bms wrote:

Wouldn't atomics be more appropriate for higher PPS yield?

Well, my goal here wasn't related to PPS or any performance metric, I just wanted to fix a misuse of kernel interfaces. I do expect there will be some work done to improve mcast forwarding performance once the multi-FIB-aware patches land.

Directly modifying the code to use atomic operations might help, so long as different CPUs aren't frequently contending to update the same counter. The per-VIF counters would probably be better-served by being converted to counter(9).

Directly modifying the code to use atomic operations might help, so long as different CPUs aren't frequently contending to update the same counter. The per-VIF counters would probably be better-served by being converted to counter(9).

Fair enough. I think Pavlin was responsible for much of this code originally; he has since been sucked into the Googleplex.