From: Patrick McHardy <kaber@trash.net>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH] netfilter: nf_conntrack_tstamp: add flow-based timestamp extension
Date: Thu, 13 Jan 2011 20:10:23 +0100 [thread overview]
Message-ID: <4D2F4E1F.4070403@trash.net> (raw)
In-Reply-To: <20110113123030.3407.59986.stgit@decadence>
Am 13.01.2011 13:30, schrieb Pablo Neira Ayuso:
> This patch adds flow-based timestamping for conntracks. This
> conntrack extension is disabled by default. Basically, we use
> two 64-bits variables to store the creation timestamp once the
> conntrack has been confirmed and the other to store the deletion
> time. This extension is disabled by default, to enable it, you
> have to:
>
> echo 1 > /proc/sys/net/netfilter/nf_conntrack_timestamp
>
> This patch allows to save memory for user-space flow-based
> loogers such as ulogd2. In short, ulogd2 does not need to
> keep a hashtable with the conntrack in user-space to know
> when they were created and destroyed, instead we use the
> kernel timestamp. If we want to have a sane IPFIX implementation
> in user-space, this nanosecs resolution timestamps are also
> useful. Other custom user-space applications can benefit from
> this via libnetfilter_conntrack.
No general objections from me.
> This patch does not modifies the /proc output to display
> the start timestamping in nanosecs (which is not very useful).
> We would need some generic functions similar to those in
> xt_time to convert that output to local time in the kernel.
> I think that ctnetlink is better for this, we pass the
> timestamps in nanosecs and we call localtime() in the
> user-space application. For that reason, I decided to only
> modify the ctnetlink part (including dumping and event
> notifications).
Just as an idea, showing the time-delta (aka lifetime)
of the connection could be interesting and doesn't
require any timezone conversions. But this could
certainly be done in a follow up patch.
> --- /dev/null
> +++ b/include/net/netfilter/nf_conntrack_timestamp.h
> @@ -0,0 +1,45 @@
> +#ifndef _NF_CONNTRACK_TSTAMP_H
> +#define _NF_CONNTRACK_TSTAMP_H
> +
> +#include <net/net_namespace.h>
> +#include <linux/netfilter/nf_conntrack_common.h>
> +#include <linux/netfilter/nf_conntrack_tuple_common.h>
> +#include <net/netfilter/nf_conntrack.h>
> +#include <net/netfilter/nf_conntrack_extend.h>
> +
> +struct nf_conn_tstamp {
> + u_int64_t start;
> + u_int64_t stop;
> +};
> +
> +static inline
> +struct nf_conn_tstamp *nf_conn_tstamp_find(const struct nf_conn *ct)
> +{
> + return nf_ct_ext_find(ct, NF_CT_EXT_TSTAMP);
> +}
> +
> +static inline
> +struct nf_conn_tstamp *nf_ct_tstamp_ext_add(struct nf_conn *ct, gfp_t gfp)
> +{
> + struct net *net = nf_ct_net(ct);
> +
> + if (!net->ct.sysctl_tstamp)
> + return NULL;
> +
> + return nf_ct_ext_add(ct, NF_CT_EXT_TSTAMP, gfp);
How about making this configurable at compile time to avoid any overhead
(memory in ct_extend and runtime) for anyone not needing it like most
of the other ct_extend options?
next prev parent reply other threads:[~2011-01-13 19:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-13 12:30 [PATCH] netfilter: nf_conntrack_tstamp: add flow-based timestamp extension Pablo Neira Ayuso
2011-01-13 15:40 ` Pablo Neira Ayuso
2011-01-13 19:00 ` Patrick McHardy
2011-01-13 19:10 ` Patrick McHardy [this message]
2011-01-14 11:58 ` Pablo Neira Ayuso
2011-01-14 12:15 ` Patrick McHardy
-- strict thread matches above, loose matches on Subject: below --
2011-01-18 19:27 Pablo Neira Ayuso
2011-01-19 15:01 ` Patrick McHardy
2011-01-16 22:33 Pablo Neira Ayuso
2011-01-18 13:59 ` Patrick McHardy
2010-10-24 15:25 Pablo Neira Ayuso
2010-10-25 16:00 ` Patrick McHardy
2010-10-23 17:23 Pablo Neira Ayuso
2010-10-24 1:30 ` Changli Gao
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=4D2F4E1F.4070403@trash.net \
--to=kaber@trash.net \
--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 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.