Correlation of hashsize, maxelem and bucketsize ipset references by iptables

I'm trying to understand the correlation of the parameters hashsize, maxelem and bucketsize for ipsets and their behavior if and if not referenced by iptables. With "understand" I also mean "derive meaningful recommendations and implications for setup planning". Probably the easiest is maxelem, but as I found contradicting information, I want to clarify as well: This is the maximum amount of elements stored in the set, completely independent of the other values. It's specified during the create command and cannot be adjusted later on. bucketsize for itself is probably easy enough by itself as well. Assuming it's set to 2 and we have two elements which generate the same hash, the bucket is full. It becomes more interesting later on. hashsize is described as the initial hash size of the set. It's also mentioned that to avoid clashes and a limited number of chaining (what is this? Is chaining referring to the bucket?) doubling of the hash size is performed. Assuming I have hashsize 64, maxelem 1000 and bucketsize 2 I understand the hashtable has 64 lines/fields and the corresponding memory reserved. Assuming I add elements which generate perfectly spread hashes, adding the 65th element would fill the first bucket. With the 128th element being added, all buckets would be full. It becomes interesting when the 129th element is added. It would be added to a already full bucket and therefore leading to the hashsize being doubled, making it 128. This would trigger a re-hashing of all elements and assuming a perfect spread, putting a single element per bucket, except one bucket which as 2 elements. Assuming a not perfect spread, leading to three elements in a bucket, this would lead to another round of doubling and rehashing, getting us to 256 hashsize and respectively higher memory usage. Let's call this process **resizing** for reference below. This pretty much goes on, until we want to add the 1001th element, which is blocked due to maxelem being reached, no respect given to the other properties. If an iptable references the ipset, resizing does not happen, no matter what. The theoretical maximum of elements stored in an ipset is therefore the lower of 'maxelem' or 'hashsize * bucketsize'. Performance implications: Hashing is about O(1), so the hashsize does not affect the performance really. Compare operations may be required for each entry in the bucket, which are always in addition to the hash operation, so the bigger the bucketsize, the slower. Memory implications: The higher the hashsize, the more memory needs to be reserved. I would have assumed that doubling the hashsize doubles the memory but a test with ipset v7.19 revealed that for hashsize <= 1024 the Size in memory: is always 456. The following table show the consumption on an empty set and with one element: |hashlen|Empty Set (Bit in memory) |Empty Set. Diff to prev.| Mem with 1 ele.| Element Mem. in Bit | |-|-|-|-|-| |<=1024|456|-|504|48| |2048|480|24|528|48| |4096|528|48|576|48| |8192|624|96|672|48| |16384|816|192|864|48| |...|...|...|...|48| |1048576 (2^20)|25008|...|...|48| |16777216 (2^24)|393648|...|...|48| From the numbers I derive that on any modern system which is not **very** restricted on memory, I don't see any reason to not use the biggest meaningful hashsize and smallest possible bucketsize. So the overall memory consumption depends **way** more on the amount of stored elements than the hashlen **Personal recommendation and interpretation**: I would derive a rule of thump of "Amount of expected entries * 8" for hashsize and a bucketsize of 14. This should leave one with very good performance, reasonable memory consumption and especially very unlikely issues with restriction put in place by iptables, which makes resizing of existing sets impossible while referenced. Bucketsize 14 does not have any effect really if only one entry is in, and with using the maximum, making it very unlikely issues ever occur - so nothing lost, especially as extending hashsize not possible once referenced by iptables. Now the question(s): - Is my interpretation of the parameters and their mutual impact correct? - Is anything off with my interpretation of the memory results? I wonder especially as 1024 is very little (would cover ~125 entries in my recommendation).