Rounding behavor of --max-flows is confusing

[gandro]

Currently, --max-flows bumps up to the next (2^n)-1.

--max-flows uint32   Max number of flows to store in memory (gets rounded up to closest (2^n)-1 (default 131071)

Examples:

1000 -> 1024
1023 -> 1024
1024 -> 2048

As a user, I find this behavior confusing. I would expect --max-flows 1024 to be rounded as 1024, not bumped up to 2048.

[rolinh]

Note that this is due to ring buffer implementation details: even if max flows number is changed to not appear rounded to the next power of 2 to the user, unless the ring implementation is changed, the ring buffer will still be allocated with a size rounded to the next power of 2.
Ultimately, I don't think that this is so trivial to fix so I'd remove the good-first-issue label.

[glibsm]

I think there is an easy way out of here where we treat 2n-1 and 2n as actual 2*n-1 capacity. I certainly wouldn't expect 1024 to be upgraded to 2047 in reality, if that makes any sense.

We don't need to modify the actual internals that much, just how we interpret this one-off thing (one off is due to us needing a mask of 1s that covers the entire capacity)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.