Re: [RFC] conntrack event framework speedup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 15, 2022 at 01:05:38PM +0100, Florian Westphal wrote:
> Hello,
> 
> Due to net.netfilter.nf_conntrack_events=1 we eat some uncessesary
> overhead:
> 
> 1. allocation of new conntrack entries needs to alloc ct->ext
> 2. inverse for deletion/free.
> 3. Because the ctnetlink module is typically active, each packet will
>    end up calling __nf_conntrack_eventmask_report via nf_confirm() and
>    then in ctnetlink only to find that we have no listeners
>    (and we can't call nfnetlink_has_listeners() from conntrack because
>     that would yield a dependency of conntrack to nfnetlink).
> 
> I would propose to add minimal conntrack specific code
> to nfnetlink, namely, to add bind()(/unbind() calls that inc/dec a
> counter for each ctnetlink event listener/socket.
> If counter becomes nonzero, flip a bit in struct net.
> 
> This would allow us to do the following:
> 
> 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?

> in nfnetlink bind, inc pernet counter when event group is bound.
> in nfnetlink unbind, dec pernet counter when event group is unbound.

So you keep one counter per netlink group in netns area?

> in init_conntrack() allocate the event cache extension only if
>  a) nf_conntrack_events == 1, or
>  b) nf_conntrack_events == 2 and pernet counter is nonzero.
> 
> Extend nf_confirm() to check of the pernet counter before
> call to __nf_conntrack_eventmask_report().
> 
> If nobody spots a problem with this idea I'd start to work on
> a prototype.

There is also setsockopt() to subscribe to netlink groups, you might
need to extend netlink_kernel_cfg to deal with this case too?



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux