From: Daniel Borkmann <daniel@iogearbox.net>
To: Patrick McHardy <kaber@trash.net>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
David Laight <David.Laight@aculab.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"tgraf@suug.ch" <tgraf@suug.ch>,
"pablo@netfilter.org" <pablo@netfilter.org>,
"johunt@akamai.com" <johunt@akamai.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH net 2/2] rhashtable: remove indirection for grow/shrink decision functions
Date: Thu, 26 Feb 2015 09:54:08 +0100 [thread overview]
Message-ID: <54EEDF30.4080505@iogearbox.net> (raw)
In-Reply-To: <20150226075354.GA30061@acer.localdomain>
On 02/26/2015 08:53 AM, Patrick McHardy wrote:
> On 25.02, Alexei Starovoitov wrote:
>> On Wed, Feb 25, 2015 at 12:10 PM, Patrick McHardy <kaber@trash.net> wrote:
>>> On 25.02, Eric Dumazet wrote:
>>>> But if any workload had to grow the table to 2^20 slots, we had to
>>>> consume GB of memory anyway to hold sockets and everything.
>>>>
>>>> Trying to shrink is simply not worth it, unless you expect your host
>>>> never reboots and you desperately need back these 8 MBytes of memory.
>>>
>>> That may be true in the TCP case, but for not for nftables. We might
>>> have many sets and, especially when used to represent more complicated
>>> classification algorithms, their size might change by a lot.
>>
>> sounds like grow/shrink decision cannot be generalized within
>> rhashtable, but two callbacks are about to be removed and the
>> are costly. So would it make sense to disable auto-expand/shrink
>> completely and let nft/tcp call expand/shrink when needed?
>
> My understanding was that Eric was arguing against shrinking in general.
> But assuming we have it, what's the downside of also performing
> shrinking for TCP?
>
>> nft can potentially do smarter batching this way.
>> If it sees a lot of entries are about to be inserted, it can call
>> expand directly to quickly grow sparsely populated table
>> into large one, and then insert all the entries.
>> That will mitigate 'slow rcu' issue as well.
>
> I like that idea.
I think shrinking/expanding could still be configurable when we
get there. Perhaps as a flag parameter, definitely something more
lightweight at least, as both grow/shrink decision functions seem
to be quite reusable and could therefore stay private.
Perhaps those users that want to specifically optimize grow/shrink
could then disallow auto-expand/shrink from within rhashtable (via
initialization parameters) and could use the APIs directly, which
we need to expose then. That way we can keep it simple for netlink,
tipc and what else pops up.
next prev parent reply other threads:[~2015-02-26 9:09 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-25 22:09 [PATCH net 2/2] rhashtable: remove indirection for grow/shrink decision functions Alexei Starovoitov
2015-02-26 7:53 ` Patrick McHardy
2015-02-26 8:54 ` Daniel Borkmann [this message]
2015-02-26 14:50 ` Eric Dumazet
2015-02-26 14:54 ` Patrick McHardy
2015-02-26 15:20 ` [PATCH net] rhashtable: use cond_resched() Eric Dumazet
2015-02-26 15:36 ` David Laight
2015-02-26 15:46 ` Patrick McHardy
2015-02-26 16:03 ` David Laight
2015-02-26 15:50 ` Daniel Borkmann
2015-02-27 22:55 ` David Miller
-- strict thread matches above, loose matches on Subject: below --
2015-02-25 15:31 [PATCH net 0/2] rhashtable updates Daniel Borkmann
2015-02-25 15:31 ` [PATCH net 2/2] rhashtable: remove indirection for grow/shrink decision functions Daniel Borkmann
2015-02-25 15:41 ` David Laight
2015-02-25 15:46 ` Daniel Borkmann
2015-02-25 15:51 ` David Laight
2015-02-25 16:14 ` Daniel Borkmann
2015-02-25 17:41 ` Eric Dumazet
2015-02-25 17:49 ` David Laight
2015-02-25 18:15 ` Eric Dumazet
2015-02-25 18:56 ` Daniel Borkmann
2015-02-25 19:52 ` Eric Dumazet
2015-02-25 20:10 ` Patrick McHardy
2015-02-26 10:02 ` tgraf
2015-02-27 22:30 ` David Miller
2015-02-28 0:48 ` Patrick McHardy
2015-02-28 1:35 ` David Miller
2015-02-26 14:18 ` David Laight
2015-03-11 6:42 ` Herbert Xu
2015-03-12 16:57 ` Thomas Graf
2015-03-13 7:06 ` Herbert Xu
2015-02-25 17:23 ` Thomas Graf
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=54EEDF30.4080505@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=David.Laight@aculab.com \
--cc=alexei.starovoitov@gmail.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=johunt@akamai.com \
--cc=kaber@trash.net \
--cc=netdev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).