All of lore.kernel.org
 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 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.