On 02/24/2015 07:18 PM, David Miller wrote:
...
I've already said today that I think this whole indirection stuff
with grow and shrink decisions should simply go away.
Everyone defines it to the generic rhashtable routine, therefore
that should just be made private to lib/rhashtable.c, called
directly, and the methods completely removed.
Given that, this change makes no sense.
When a limit is not specified, we should unconditionally grow rather
than refuse to grow. One should not be required to specify this at
all. If you have no idea what limit might be reasonable, you specify
nothing at all and just let available memory be the limiting factor.
I agree.
Fwiw, I believe this behavior came in as a regression via commit
c0c09bfdc415 ("rhashtable: avoid unnecessary wakeup for worker queue").
Initially, if no max_shift was specified, we'd just expand further.
I can take care of these above two fixups tomorrow, if you want.
I presume you want to route both via -net, or just the growth limit
issue via -net?
I also have some optimizations I was working on last week for
net-next, but I would wait for a -net into -net-next merge after
that to avoid merge conflicts, if that's fine. ;)
Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
