From: Patrick McHardy <kaber@trash.net>
To: Krzysztof Oledzki <ole@ans.pl>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH] Accounting rework: ct_extend + 64bit counters
Date: Tue, 03 Jun 2008 18:40:52 +0200 [thread overview]
Message-ID: <48457414.4050509@trash.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0806031830250.3438@bizon.gios.gov.pl>
Krzysztof Oledzki wrote:
>
>
> On Tue, 3 Jun 2008, Patrick McHardy wrote:
>
>> Krzysztof Oledzki wrote:
>>> On Tue, 3 Jun 2008, Patrick McHardy wrote:
>>>
>>>>> + nf_conntrack.acct=
>>>>> + [NETFILTER] Enable connection tracking flow accounting
>>>>> + 0 to disable accounting (default)
>>>>> + 1 to enable accounting
>>>>
>>>> Changing the default will probably result in surprises.
>>>> How about we make a config option (CONFIG_NF_ACCT_COMPAT)
>>>> that makes it default to 1 and print a warning that this
>>>> option is going to be removed/the default changed. Then
>>>> we add a target to manually enable accounting on a per-connection
>>>> base and kill off the compat option after a couple of
>>>> month.
>>>
>>> As far as I know there is now way to enable accounting on a
>>> per-connection base with a target as it is not possible to ad
>>> ct_extend to confirmed conntracks.
>>
>> You can add it to unconfirmed conntracks though.
>
> With a target? How?
Mhh good point :) I was thinking of calling it from the raw table,
but of course we don't have a conntrack at that point. So the
information would have to be propagated from the raw table somehow.
Maybe something like the untracked conntrack? IIRC someone posted
a patch for something similar (propagation of parameters to helpers)
some time ago.
>>> However, I think we may still use CONFIG_NF_CT_ACCT but only to set a
>>> default value of this (nf_ct_acct) variable, is that acceptable?
>>
>> We should move towards getting rid of the default value,
>> having this depend on a config option must only be a temporary
>> solution.
>
> Fine. So I add this together with an entry in feature-removal-schedule.txt.
>
>> So we'd still need a target to enable it manually
>
> Do you mean an iptables target (-j ...)? IMHO a kernel/module option
> plus a sysctl/sysfs interface should be enough.
Having it controlled through an iptables target would be preferrable
because you can then do selective accounting.
next prev parent reply other threads:[~2008-06-03 16:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-02 17:24 [PATCH] Accounting rework: ct_extend + 64bit counters Krzysztof Oledzki
2008-06-02 17:41 ` Fabian Hugelshofer
2008-06-02 18:05 ` Krzysztof Oledzki
2008-06-03 13:30 ` Patrick McHardy
2008-06-03 16:23 ` Krzysztof Oledzki
2008-06-03 16:28 ` Patrick McHardy
2008-06-03 16:35 ` Krzysztof Oledzki
2008-06-03 16:40 ` Patrick McHardy [this message]
2008-06-03 16:49 ` Krzysztof Oledzki
2008-06-03 17:14 ` Patrick McHardy
2008-06-03 17:19 ` Krzysztof Oledzki
2008-06-03 17:21 ` Patrick McHardy
2008-06-03 17:35 ` Krzysztof Oledzki
2008-06-03 17:57 ` Patrick McHardy
2008-06-03 18:10 ` Krzysztof Oledzki
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=48457414.4050509@trash.net \
--to=kaber@trash.net \
--cc=netfilter-devel@vger.kernel.org \
--cc=ole@ans.pl \
/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.