You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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 hasherThe text was updated successfully, but these errors were encountered: