On Thu, Sep 05, 2013 at 04:58:40PM +0200, Valentina Giusti wrote:
> Hi,
>
> On 09/05/2013 10:27 AM, Pablo Neira Ayuso wrote:
> >On Thu, Sep 05, 2013 at 09:58:52AM +0200, Valentina Giusti wrote:
> >[...]
> >>As I mentioned, there are
> >>
> >>"applications (e.g. connman) which currently need to keep polling
> >>accounting objects via nfnl_acct_get() in order to get updated
> >>statistics. This is far from ideal in scenarios with large amounts
> >>of accounting objects and diverse, unpredictable network traffic."
> >
> >You get around 100 accounting objects with one single recv syscall on
> >x86_64 when polling from userspace. If you're noticing performance
> >issues with this approach, please report them more precisely.
>
> It's actually rather a conceptual matter here.
> Requesting notifications from userspace via nfnl_acct_get() implies
> that for each and every one of them, userspace has to make a new
> query. Is polling for stats better than receiving notifications
> from the kernel?
The question is that you're proposing to move the complexity from user
to kernel-space to resolve this problem, which results in more kernel
LOC for a very specific task. I think we can make it in a more generic
way.
My suggestion is to extend the iptables nfacct match to match if the
bytes/packets have passed some user-define threshold, then use the
NFLOG target to report such situation.
The hypothetical iptables command line would look like:
-m nfacct --nfacct-name test --above-bytes 1000 --match-once \
-j NFLOG --nflog-prefix "test"
You can add a new nfacct match revision to implement this new feature.
Regards.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
