netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Patrick McHardy <kaber@trash.net>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH] netfilter: nf_conntrack_tstamp: add flow-based timestamp extension
Date: Fri, 14 Jan 2011 12:58:53 +0100	[thread overview]
Message-ID: <4D303A7D.30002@netfilter.org> (raw)
In-Reply-To: <4D2F4E1F.4070403@trash.net>

On 13/01/11 20:10, Patrick McHardy wrote:
> 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.

That's interesting indeed. We can obtain the current time in
ct_seq_start and store it in ct_iter_state, then calculate the
time-delta for each flow entry to display this in the /proc output. The
conntrack tool can do similar but in user-space.

>> --- /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?

I'm fine with this, I'll add it.

Looking at the source, should we do the same with the accounting? I
remember that we decided to remove this compile-time option time ago.

  reply	other threads:[~2011-01-14 11:59 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
2011-01-14 11:58   ` Pablo Neira Ayuso [this message]
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=4D303A7D.30002@netfilter.org \
    --to=pablo@netfilter.org \
    --cc=kaber@trash.net \
    --cc=netfilter-devel@vger.kernel.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 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).