From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: Phil Sutter <phil@nwl.cc>, netfilter-devel@vger.kernel.org
Subject: Re: [nf-next RFC] netfilter: nf_tables: Feature ifname-based hook registration
Date: Mon, 7 Jul 2025 21:25:50 +0200 [thread overview]
Message-ID: <aGwfPqpymU17BFHw@calendula> (raw)
In-Reply-To: <aGffdwjA23MaNgPQ@strlen.de>
On Fri, Jul 04, 2025 at 04:04:39PM +0200, Florian Westphal wrote:
> Phil Sutter <phil@nwl.cc> wrote:
> > Please keep in mind we already have 'nft list hooks' which provides
> > hints in that direction. It does not show which flowtable/chain actually
> > binds to a given device, though.
>
> Its possible to extend it:
> - add NF_HOOK_OP_NFT_FT to enum nf_hook_ops_type
> - add
>
> static int nfnl_hook_put_nft_ft_info(struct sk_buff *nlskb,
> const struct nfnl_dump_hook_data *ctx,
> unsigned int seq,
> struct nf_flowtable *ft)
>
> to nfnetlink_hook.c
>
> it can use container_of to get to the nft_flowtable struct.
> It might be possibe to share some code with nfnl_hook_put_nft_chain_info
> and reuse some of the same netlink attributes.
>
> - call it from nfnl_hook_dump_one.
>
> I think it would use useful to have, independent of "eth*" support.
This is a good idea to place this in nfnetlink_hook, that
infrastructure is for debugging purpose indeed.
If this update is made, I also think it makes sense to remove the
netlink event notification code for devices, I don't have a use case
for that code in the new device group other than debugging.
If Phil's intention is to make code savings, then extending
nfnetlink_hook and removing the existing device notification group
make sense to me.
User can simply resort to check via dump if a matching hook is
registered for eth* in nfnetlink_hook.
next prev parent reply other threads:[~2025-07-07 19:25 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-02 17:47 [nf-next RFC] netfilter: nf_tables: Feature ifname-based hook registration Phil Sutter
2025-07-02 22:39 ` Florian Westphal
2025-07-03 10:21 ` Phil Sutter
2025-07-03 11:35 ` Pablo Neira Ayuso
2025-07-03 12:09 ` Florian Westphal
2025-07-03 12:37 ` Phil Sutter
2025-07-03 12:25 ` Phil Sutter
2025-07-03 12:39 ` Florian Westphal
2025-07-03 12:47 ` Phil Sutter
2025-07-03 12:54 ` Florian Westphal
2025-07-03 13:17 ` Phil Sutter
2025-07-03 14:19 ` Pablo Neira Ayuso
2025-07-03 14:33 ` Phil Sutter
2025-07-03 21:32 ` Pablo Neira Ayuso
2025-07-04 12:41 ` Phil Sutter
2025-07-04 14:04 ` Florian Westphal
2025-07-04 15:33 ` Phil Sutter
2025-07-07 19:25 ` Pablo Neira Ayuso [this message]
2025-07-08 14:38 ` Phil Sutter
2025-07-09 22:43 ` Pablo Neira Ayuso
2025-07-10 13:55 ` Phil Sutter
2025-07-11 12:19 ` Phil Sutter
2025-07-11 13:16 ` Florian Westphal
2025-07-11 13:43 ` Phil Sutter
2025-07-11 13:48 ` Florian Westphal
2025-07-11 14:52 ` Pablo Neira Ayuso
2025-07-11 16:39 ` Phil Sutter
2025-07-14 14:02 ` Pablo Neira Ayuso
2025-07-03 11:55 ` Florian Westphal
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=aGwfPqpymU17BFHw@calendula \
--to=pablo@netfilter.org \
--cc=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=phil@nwl.cc \
/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.