All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Lafaye <jlafaye@gmail.com>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: Packet statistics accounting module: request for comments
Date: Tue, 4 Oct 2011 21:03:21 +0200	[thread overview]
Message-ID: <CAFAca_CH4QD-7XngGE=H_pTKo+gN3F_nf2RTf+1S8kbvPXkj-g@mail.gmail.com> (raw)
In-Reply-To: <alpine.LNX.2.01.1110041256500.22180@frira.zrqbmnf.qr>

On Tue, Oct 4, 2011 at 1:02 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
> On Tuesday 2011-10-04 06:50, Julien Lafaye wrote:
>>
>>I created a small packet statistics accounting module based on the
>>xtables framework. It is based on a FIFO that is filled in netfilter
>>hooks and emptied by a user program reading statistics through /proc
>>callbacks. The goal of the module is to be able to get maximum traffic
>>rate with an improved resolution compared to basic techniques. Typical
>>expected resolution is 100ms.
>
> I am thinking of how xt_quota2 (in grow mode) could have been enhanced
> to simply reset the counter when the procfs file is read. How would that
> have compared to your module?

My objective was to count incoming packets & bytes received during
short time frames, i.e. 100ms even 10ms. I first thought of having a
user program polling statistics but I would have to rely on accurate
scheduling of the polling process by the OS. I wanted to be able to
deploy the accounting module on Centos 5 kernels (2.6.18) which does
not have the dynticks features and no guarantee that the polling
process will be awakened when I wanted it to be. So, I chose to build
time buckets directly in the softirq handler and export them with
/proc. I agree that polling the xt_quota2 counter and resetting at
each poll will achieve the same functionality but I would run tests to
check that polling is actually scheduled at regular enough intervals.

>>The code is currently stored in github:
>>https://github.com/jlafaye/xt_pktstat
>>
>>I would like the code to be considered for inclusion in the
>>xtables-addons framework. Nevertheless, the code might not be mature
>>enough as this is the first time I do kernel programming. Although
>>advised by knowledgeable persons, there are probably many issues in it.
>
> The .c files need a little license-mentioning header at the least, and
> should in principle also use tab indents like LKCS.-See files from Xt-a
> for examples.

OK

  reply	other threads:[~2011-10-04 19:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-04  4:50 Packet statistics accounting module: request for comments Julien Lafaye
2011-10-04 11:02 ` Jan Engelhardt
2011-10-04 19:03   ` Julien Lafaye [this message]
2011-10-04 20:27     ` Jan Engelhardt
2011-10-05 19:27       ` Julien Lafaye

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='CAFAca_CH4QD-7XngGE=H_pTKo+gN3F_nf2RTf+1S8kbvPXkj-g@mail.gmail.com' \
    --to=jlafaye@gmail.com \
    --cc=jengelh@medozas.de \
    --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.