All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: David Miller <davem@davemloft.net>, johunt@akamai.com
Cc: pablo@netfilter.org, kaber@trash.net, tgraf@suug.ch,
	netfilter-devel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v2 1/2] rhashtable: require max_shift if grow_decision defined
Date: Tue, 24 Feb 2015 20:48:10 +0100	[thread overview]
Message-ID: <54ECD57A.1080709@iogearbox.net> (raw)
In-Reply-To: <20150224.131828.1632037288300527014.davem@davemloft.net>

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

  reply	other threads:[~2015-02-24 19:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-24 16:10 [PATCH v2 0/2] nft hash resize fixes Josh Hunt
2015-02-24 16:10 ` [PATCH v2 1/2] rhashtable: require max_shift if grow_decision defined Josh Hunt
2015-02-24 16:40   ` Thomas Graf
2015-02-24 18:18   ` David Miller
2015-02-24 19:48     ` Daniel Borkmann [this message]
2015-02-24 21:31       ` David Miller
2015-02-24 22:49         ` Thomas Graf
2015-02-25  2:12           ` David Miller
2015-02-24 22:36     ` Josh Hunt
2015-02-24 16:10 ` [PATCH v2 2/2] nft_hash: define max_shift rhashtable parameter Josh Hunt
2015-02-24 16:42   ` Thomas Graf
2015-02-24 17:03     ` Josh Hunt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54ECD57A.1080709@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=johunt@akamai.com \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=tgraf@suug.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.