From: Pablo Neira Ayuso <pablo@netfilter.org>
To: netfilter-devel@vger.kernel.org, Krzysztof Piotr Oledzki <ole@ans.pl>
Subject: Re: [PATCH RFC 3/3] acct: add input and output interface index
Date: Sun, 3 Nov 2013 21:59:15 +0100 [thread overview]
Message-ID: <20131103205915.GA8264@localhost> (raw)
In-Reply-To: <20131017113345.GQ13405@imap.eitzenberger.org>
On Thu, Oct 17, 2013 at 01:33:45PM +0200, Holger Eitzenberger wrote:
> Hi Pablo,
>
> > I like patches 1/3 and 2/3, they are nice cleanups.
>
> thanks for looking into this.
I'm going to apply 1/3 and 2/3 with some small glitches, I would like
not to lose these cleanups.
> > If you only set indev/outdev once we can skip the conntrack extension
> > by passing the skb to nf_ct_deliver_cached_events and include this
> > information in the conntrack events. That would not allow to dump the
> > device from conntrack dumps though. I still have concerns with this
> > approach as this doesn't seem to cover the scenario in which the
> > in/outdev changes.
>
> I know that doing it this simiple way is only "best effort", as e. g.
> with IP multipathing or 802.3ad this information is not % correct
> in all cases.
>
> And the question we have to answer is whether this interface
> information *has* to be correct in every case, even the less commonly
> used cases.
>
> For IPFIX I would answer this question with a 'no'.
>
> And we can later extend this to update the interface information
> correctly in every case. It's only a few patches away.
My suggestion is to rework patch 3/3 to pass the interface information
to nf_ct_deliver_cached_events via nf_ct_event struct, then include it
in the event message. Thus, we don't need to increase the size the
conntrack. The downside of this approach is that we cannot retrieve
the interface via dump operation, but I think it should be enough for
IPFIX. This feature should be disabled by default, so please add a
/proc switch to enable/disable it in runtime.
Thanks.
prev parent reply other threads:[~2013-11-03 20:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-26 15:31 [PATCH RFC 0/3] conntrack: add interface information to accounting extend Holger Eitzenberger
2013-09-26 15:31 ` [PATCH RFC 1/3] acct: introduce nf_conn_acct Holger Eitzenberger
2013-09-26 15:31 ` [PATCH RFC 2/3] ctnetlink: account both directions in one step Holger Eitzenberger
2013-09-26 15:31 ` [PATCH RFC 3/3] acct: add input and output interface index Holger Eitzenberger
2013-10-17 11:06 ` Pablo Neira Ayuso
2013-10-17 11:33 ` Holger Eitzenberger
2013-11-03 20:59 ` Pablo Neira Ayuso [this message]
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=20131103205915.GA8264@localhost \
--to=pablo@netfilter.org \
--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 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).