replace simple IP pool free table with LRU implementation #450
Conversation
The free table was effectively acting as a queue (LRU). push and pop operation where fast, but a direct removal of a single item did require a full table scan. For large IP pools, that could lead to unacceptable delays. The LRU implementation uses two indexes and is much faster when removing an item from the middle of the queue.
|
Do we have metrics comparing the old implementation to this one? Also, since authentication will fill in a value using the Framed-IP-Address, can a dummy pool be used returning a fixed IP that will always be overwritten by the RADIUS server? |
The old implementation achieves 4 ops/s on a /10 prefix, the new version about 500000 ops/s, and a maps and gb_trees based version about 200000 ops/s (all measured for the take operation).
There is nothing that dictates that a pool can not be shared between AAA based assignment and local assignment. Using a dummy pool is therefore not an option. |
|
Ok, I'm not sure I follow the pool config. So we would have a pool (a collection of prefixed IP addresses) that would be shared among AAA and local. I assume AAA and local will not track each other's assignments, or do they? If they don't, can't they have separate, non overlapping pools covering the overall pool? |
The ergw pool tracks the IP assigned by AAA, that is whole purpose of the AAA gets told which session has which IP, so it can track the used IPs. In a normal NAS (Network Access Server), e.g. Cisco BNG, nothing stops AAA to issue static IPs from a pool shared with the NAS as long as the IP is unused. There is also no technical requirement to have seperate pool types for AAA and local assignments. Also, the design decision to have a unified pool logic was made long ago. I don't see any need to question or revisit that in a PR that implements a performance optimization. |
|
Thanks for the detailed explanation. Understanding the rationale for design decisions is also important, and not obvious at first glance. Also, assumptions for design decisions sometimes change. |
The free table was effectively acting as a queue (LRU). push and
pop operation where fast, but a direct removal of a single item
did require a full table scan.
For large IP pools, that could lead to unacceptable delays.
The LRU implementation uses two indexes and is much faster when
removing an item from the middle of the queue.