From: Florian Westphal <fw@strlen•de>
To: Scott Mitchell <scott.k.mitch1@gmail•com>
Cc: Pablo Neira Ayuso <pablo@netfilter•org>,
kadlec@netfilter•org, phil@nwl•cc, davem@davemloft•net,
edumazet@google•com, kuba@kernel•org, pabeni@redhat•com,
horms@kernel•org, netfilter-devel@vger•kernel.org,
coreteam@netfilter•org, netdev@vger•kernel.org,
linux-kernel@vger•kernel.org, syzbot@syzkaller•appspotmail.com
Subject: Re: [PATCH v5] netfilter: nfnetlink_queue: optimize verdict lookup with hash table
Date: Thu, 15 Jan 2026 18:07:03 +0100 [thread overview]
Message-ID: <aWketzn78tzo5anB@strlen.de> (raw)
In-Reply-To: <CAFn2buDeCxJp3OHDifc5yX0pQndmLCKc=PShT+6Jq3-uy8C-OA@mail.gmail.com>
Scott Mitchell <scott.k.mitch1@gmail•com> wrote:
> > > + NFQA_CFG_HASH_SIZE, /* __u32 hash table size (rounded to power of 2) */
> >
> > This should use the rhashtable implementation, I don't find a good
> > reason why this is not used in first place for this enhancement.
>
> Thank you for the review! I can make the changes. Before implementing,
> I have a few questions to ensure I understand the preferred approach:
>
> 1. For the "perns" allocation comment - which approach did you have in mind:
> a) Shared rhashtable in nfnl_queue_net (initialized in
> nfnl_queue_net_init) with key={queue_num, packet_id}
> b) Per-instance rhashtable in nfqnl_instance, with lock refactoring
You could also go with c), single rhashtable created at module init
time, like what af_netlink.c is doing.
hash and compare function would then have to include struct net *
in the hash and the compare.
b) makes no sense; if you do the lock refactoring to also allow
GFP_ACCOUNT you could also keep the existing hashtable approach,
I think.
> 2. The lock refactoring (GFP_ATOMIC → GFP_KERNEL) is independent of
> the hash structure choice, correct? We could fix that separately?
Not needed if you go with a) or c).
> 3. Can you help me understand the trade-offs you considered for
> rhashtable vs hlist_head? Removing the API makes sense, and I want to
> better understand how to weigh that against runtime overhead (RCU,
> locks, atomic ops) for future design decisions.
I think for this not using rhashtable is fine, but as-is the patch would
allow almost unlimited memory consumption due to ability to create 64k
queues.
next prev parent reply other threads:[~2026-01-15 17:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-22 0:37 [PATCH v5] netfilter: nfnetlink_queue: optimize verdict lookup with hash table Scott Mitchell
2025-12-03 18:33 ` Scott Mitchell
2025-12-03 18:40 ` Florian Westphal
2025-12-03 21:07 ` Scott Mitchell
2026-01-13 0:25 ` Pablo Neira Ayuso
2026-01-14 1:32 ` Scott Mitchell
2026-01-15 0:50 ` Pablo Neira Ayuso
2026-01-15 17:07 ` Florian Westphal [this message]
2026-01-17 17:33 ` Scott Mitchell
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=aWketzn78tzo5anB@strlen.de \
--to=fw@strlen$(echo .)de \
--cc=coreteam@netfilter$(echo .)org \
--cc=davem@davemloft$(echo .)net \
--cc=edumazet@google$(echo .)com \
--cc=horms@kernel$(echo .)org \
--cc=kadlec@netfilter$(echo .)org \
--cc=kuba@kernel$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=netfilter-devel@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=pablo@netfilter$(echo .)org \
--cc=phil@nwl$(echo .)cc \
--cc=scott.k.mitch1@gmail$(echo .)com \
--cc=syzbot@syzkaller$(echo .)appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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