From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>,
netfilter-devel <netfilter-devel@vger.kernel.org>
Subject: Re: [RFC] conntrack event framework speedup
Date: Tue, 15 Mar 2022 23:07:48 +0100 [thread overview]
Message-ID: <20220315220748.GC9936@breakpoint.cc> (raw)
In-Reply-To: <YjEK9RsgJuONGyTI@salvia>
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Tue, Mar 15, 2022 at 10:41:21PM +0100, Florian Westphal wrote:
> > Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > > add new net.netfilter.nf_conntrack_events default mode: 2, autodetect.
> > >
> > > Probably the sysctl entry does not make any sense anymore if you can
> > > autodetect when there is a listener?
> >
> > Hmmm, did not consider that. I *think* we still want to allow to
> > disable the feature because of xt_CT/nft_ct.
> >
> > Someone might have nf_conntrack_events=0 and tehy could be using
> > explicit configuration via templates (and then expect that only
> > those flows that matched a '-j CT' rule generate events.
>
> Maybe could you bump the ctnetlink_listeners counter when -j CT is
> used with event filtering?
Hmmm, I don't think that will work. The -j CT thing can be used to
enable event reporting (including the event type) for particular flows
only. E.g. users might do:
nf_conntrack_events=0
and then only enable destroy events for tcp traffic on port 22, 80, 443
(arbitrary example).
If I bump the listen-count, then they will see event reports for
for udp timeouts and everything else.
IDEALLY we could ditch the sysctl, the autotuning and tell users they
now need to configure events with nft/iptables but given the 'ct
helpers' thing I'm sure we'll get lots of complaits about broken event
reporting ;-)
> > @@ -691,11 +691,47 @@ static int nfnetlink_bind(struct net *net, int group)
> > if (!ss)
> > request_module_nowait("nfnetlink-subsys-%d", type);
> > +
> > + if (type == NFNL_SUBSYS_CTNETLINK) {
> > + struct nfnl_net *nfnlnet = nfnl_pernet(net);
> > +
> > + nfnl_lock(NFNL_SUBSYS_CTNETLINK);
> > + nfnlnet->ctnetlink_listeners++;
> > + if (nfnlnet->ctnetlink_listeners == 1)
> > + net->ct.ctnetlink_has_listener = true;
> > + nfnl_unlock(NFNL_SUBSYS_CTNETLINK);
> >
> > and then check 'net->ct.ctnetlink_has_listener' when allocating
> > a new conntrack.
>
> LGTM.
Thanks. I will work on a parototype along these lines and see where
that leads.
next prev parent reply other threads:[~2022-03-15 22:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-15 12:05 [RFC] conntrack event framework speedup Florian Westphal
2022-03-15 21:30 ` Pablo Neira Ayuso
2022-03-15 21:41 ` Florian Westphal
2022-03-15 21:53 ` Pablo Neira Ayuso
2022-03-15 22:07 ` Florian Westphal [this message]
2022-03-16 9:12 ` Pablo Neira Ayuso
2022-03-16 12:18 ` Florian Westphal
2022-03-17 9:13 ` Pablo Neira Ayuso
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=20220315220748.GC9936@breakpoint.cc \
--to=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
/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).