Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rework routing table (again) #538

Open
LeeSmet opened this issue Dec 31, 2024 · 0 comments
Open

Rework routing table (again) #538

LeeSmet opened this issue Dec 31, 2024 · 0 comments
Labels
type_feature New feature or request

Comments

@LeeSmet
Copy link
Contributor

LeeSmet commented Dec 31, 2024

The current routing table implementation is using a trie optimized for ips, but this data structure is not concurrent. So we wrap it in a left-right for non blocking read access while we can also write. Laslty we use arcswap as values to both deduplicate the route lists (since we have effectively 2 duplicate lists for every subnet due to the left-right), while also allowing updating of values without needing to do an actual write on the left-right.

This is now a rather complicated setup, which also has the necessary performance issues (mostly thanks to slow reads on the arcswap). Since we use static sized subnets (for now, all subnets are /64), we can remove the trie (since all values are on the same level essentially) in favour of something like a hashmap. Using something like Dashmap should hugely simplify the API, at the cost of not being able to read and write at the same time. However the time it takes to apply an update should be sufficiently small to the point that does not matter. In general, this should: simplify the codebase, and allow more update throughput. Since forwarding packets requires route lookups which themselves require loads on an arcswap, it is doubtfull that the data packet forwarding would decrease severely.

Also to further speed this up, we should consider using the Ahash crate for the map hasher implementation, as it is shown to be generally faster than the standard hasher

@LeeSmet LeeSmet added the type_feature New feature or request label Dec 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type_feature New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant