Page MenuHomeFreeBSD

netgraph/ng_bridge: Document staleness in multithreaded operation
ClosedPublic

Authored by donner on Feb 8 2021, 10:10 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 29 2024, 2:32 PM
Unknown Object (File)
Jan 18 2024, 6:31 AM
Unknown Object (File)
Dec 23 2023, 10:22 AM
Unknown Object (File)
Dec 22 2023, 11:52 PM
Unknown Object (File)
Dec 14 2023, 7:59 PM
Unknown Object (File)
Dec 10 2023, 9:50 PM
Unknown Object (File)
Dec 7 2023, 2:32 PM
Unknown Object (File)
Dec 7 2023, 2:32 PM

Details

Summary

In the data path of ng_bridge(4), the only value of an host struct,
which needs to be modified, is the staleness, which is reset every
time a frame was received. It's save to leave the code as it is.

Depends on D28545

Test Plan

No functional changes.

Diff Detail

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

Event Timeline

I don't know if counter(9) makes sense here. That's usually intended for statistical information (e.g. how many packets passed through this interface). This looks like something that wants to be protected by a lock, or implemented with an atomic.

In D28546#639111, @kp wrote:

I don't know if counter(9) makes sense here.

The only shared access to the variable is setting it to zero.
All other operations (like regular callouts and control message processing) already have a WRITER lock on the whole node.

So there is no need for any synchronization all.
The only change to make is to document this reasoning.

  • Revert "Switch staleness to counter framework."
  • Comment why it's safe to do so.
donner retitled this revision from netgraph/ng_bridge: Switch staleness to counter framework to netgraph/ng_bridge: Document staleness in multithreaded operation.Feb 9 2021, 11:35 AM
donner edited the summary of this revision. (Show Details)

OTOH it's bad, because it prevents the code from running under const constraints.

This revision is now accepted and ready to land.Feb 9 2021, 1:43 PM