On 11/30/2016 04:52 AM, Hannes Frederic Sowa wrote: > In the worst case this causes 2GB (order 19) allocations (x == 31) to > happen in GFP_ATOMIC (due to write lock) context and could cause update > failures to the routing table due to fragmentation. Are you sure the > upper limit of 31 is reasonable? I would very much prefer an upper limit > of below or equal 25 for x to stay within the bounds of the slab > allocators (which is still a lot and probably causes errors!). > Unfortunately because of the nature of the sysctl you can't really > create its own cache for it. :/ >
Agreed. I think that even something like 16 would be excessively sufficient, that would enable 65K slices, which is way more than enough to have sufficient balancing with a reasonable amount of nexthops (I wonder whether there are actual deployments with more than 32 nexthops for a route). > Also by design, one day this should all be RCU and having that much data > outstanding worries me a bit during routing table mutation. > > I am a fan of consistent hashing but I am not so sure if it belongs into > a generic ECMP implementation or into its own ipvs or netfilter module > where you specifically know how much memory to burn for it. > The complexity of the consistent hashing code might warrant something like that, but I am ot sure of the implications. > Also please convert the sysctl to a netlink attribute if you pursue this > because if I change the sysctl while my quagga is hammering the routing > table I would like to know which nodes allocate what amount of memory. Yes, that was the idea. Thanks for the feedback David
signature.asc
Description: OpenPGP digital signature
