All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2005@gmx.net>
To: Thomas Jarosch <thomas.jarosch@intra2net.com>
Cc: netfilter-devel <netfilter-devel@lists.netfilter.org>,
	Patrick McHardy <kaber@trash.net>
Subject: Re: [patch] Fix ipt_ACCOUNT for large networks - 2nd try
Date: Fri, 15 Apr 2005 01:44:19 +0200	[thread overview]
Message-ID: <425F0053.2050302@gmx.net> (raw)
In-Reply-To: <200504050948.51387.thomas.jarosch@intra2net.com>

Thomas Jarosch schrieb:
> Hi Patrick,
> 
> attached is a patch to fix the ACCOUNT target for large networks.
> This time for good ;-) Discard the patch I sent yesterday.
> 
> It runs stable now on a network with ~1300 active clients. Quoting the user:
> "Nevertheless, from performance point of view, ipt_ACCOUNT rocks. I have a
> distribution for routers (Route Hat) and last night switched from ipt_account
> to ipt_ACCOUNT completely. What took half a minute before now takes 300ms
> i.e. 100 times faster, same router, same net. Gr8 work :-)"
> 
> Cheers,
> Thomas
> 
> Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
> 
> diff -u -r -b ACCOUNT/linux/net/ipv4/netfilter/ipt_ACCOUNT.c ACCOUNT.1.4/linux/net/ipv4/netfilter/ipt_ACCOUNT.c
> --- ACCOUNT/linux/net/ipv4/netfilter/ipt_ACCOUNT.c      2004-06-13 22:41:21.000000000 +0200
> +++ ACCOUNT.1.4/linux/net/ipv4/netfilter/ipt_ACCOUNT.c  2005-04-05 09:33:52.000000000 +0200
> @@ -694,7 +694,8 @@
>  /* Copy 8 bit network data into a prepared buffer.
>     We only copy entries != 0 to increase performance.
>  */
> -static int ipt_acc_handle_copy_data(void *to_user, int *pos,
> +static int ipt_acc_handle_copy_data(void *to_user, u_int32_t *to_user_pos,
> +                                  u_int32_t *tmpbuf_pos,
>                                      struct ipt_acc_mask_24 *data,
>                                      u_int32_t net_ip, u_int32_t net_OR_mask)
>  {

You seem to like u_int32_t as a type. That causes interesting behaviour
on 64bit machines. Is there any design objective dictating that?
I have a patch available changing most occurences of u_int32_t to
something more generic (of course not for IPs, netmasks and such) which
may make sense if you ever want to use your module on 64bit machines.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

  parent reply	other threads:[~2005-04-14 23:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-05  7:48 [patch] Fix ipt_ACCOUNT for large networks - 2nd try Thomas Jarosch
2005-04-11 13:30 ` Carl-Daniel Hailfinger
2005-04-11 18:13   ` Thomas Jarosch
2005-04-14 23:44 ` Carl-Daniel Hailfinger [this message]
2005-04-15  8:29   ` Thomas Jarosch
2005-04-24 16:54   ` Patrick McHardy
2005-04-24 16:52 ` Patrick McHardy
2005-04-24 17:06   ` Thomas Jarosch

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=425F0053.2050302@gmx.net \
    --to=c-d.hailfinger.devel.2005@gmx.net \
    --cc=kaber@trash.net \
    --cc=netfilter-devel@lists.netfilter.org \
    --cc=thomas.jarosch@intra2net.com \
    /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.