"Lockless" RIB design#255
Merged
Merged
Conversation
RIB updates are handled by a single goroutine accepting update requests through a channel receiving functions to execute on the state (RIB + peer state). For lookups, we have 3 options (better to lower performance, higher to lower memory usage): 1. have a read-only copy updated "atomically" at regular interval, 2. have a read-only copy updated behind a lock at regular interval, 3. handle lookups by the worker through a high priority channel. This commit implements option 3. It may be a regression in latency compared to the previous design because long updates (flushing peers) may prevent answering lookup requests. This will be addressed in the next commit.
It can be queries without needing any lock. The user can choose between this mode and the previous one with `rib-mode`. The default value, `memory` is the previous mode. The new one can be selected with `performance`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
RIB updates are handled by a single goroutine accepting update requests
through a channel receiving functions to execute on the state (RIB +
peer state).
For lookups, we have 3 options (better to lower performance, higher to
lower memory usage):
This PR implements option 1 and 3. Option 3 may be a regression in latency compared to the previous design because long updates (flushing peers) may prevent answering lookup requests. Option 2 has not been implemented because it may make the code more complex for little gain. There is no guarantee that the garbage collector will reuse the memory just freed for the new RIB clone.
Fix #253