From: Eric Dumazet <dada1@cosmosbay.com>
To: Harald Welte <laforge@netfilter.org>
Cc: netdev@vger.kernel.org, netfilter-devel@lists.netfilter.org,
linux-kernel@vger.kernel.org, Andi Kleen <ak@suse.de>
Subject: Re: [PATCH 1/3] netfilter : 3 patches to boost ip_tables performance
Date: Thu, 22 Sep 2005 15:17:51 +0200 [thread overview]
Message-ID: <4332AEFF.1040105@cosmosbay.com> (raw)
In-Reply-To: <20050922125724.GJ26520@sunbeam.de.gnumonks.org>
Harald Welte a écrit :
> On Wed, Sep 21, 2005 at 11:29:13PM +0200, Eric Dumazet wrote:
>
>>Patch 1/3
>>
>>1) No more one rwlock_t protecting the 'curtain'
>
>
> I have no problem with this change "per se", but with the
> implementation.
>
> As of now, we live without any ugly #ifdef CONFIG_SMP / #endif sections
> in the code - and if possible, I would continue this good tradition.
>
> For example the get_counters() function. Wouldn't all the smp specific
> code (for_each_cpu(), ...) be #defined to nothing anyway?
Well... not exactly, but you are right only the first loop (SET_COUNTER) will
really do something. The if (cpu == curcpu) will be true but the compiler wont
know that, cpu and curcpu are still C variables.
>
> And if we really need the #ifdef's, I would appreciate if those
> sectionas are as small as possible. in get_counters() the section can
> definitely be smaller, rather than basically having the whole function
> body separate for smp and non-smp cases.
get_counters() is not critical, so I agree with you we can stick the general
version (not the UP optimized one)
>
> Also, how much would we loose in runtime performance if we were using a
> "rwlock_t *" even in the UP case?. I mean, it's just one more pointer
> dereference of something that is expected to be in cache anyway, isn't
> it? This gets rid of another huge set of #ifdefs that make the code
> unreadable and prone to errors being introduced later on.
>
Well, in UP case, the rwlock_t is a nulldef.
I was inspired by another use of percpu data in include/linux/genhd.h
#ifdef CONFIG_SMP
struct disk_stats *dkstats;
#else
struct disk_stats dkstats;
#endif
But if you dislike this, we can use pointer for all cases.
Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Dumazet <dada1@cosmosbay.com>
To: Harald Welte <laforge@netfilter.org>
Cc: linux-kernel@vger.kernel.org,
netfilter-devel@lists.netfilter.org, netdev@vger.kernel.org,
Andi Kleen <ak@suse.de>
Subject: Re: [PATCH 1/3] netfilter : 3 patches to boost ip_tables performance
Date: Thu, 22 Sep 2005 15:17:51 +0200 [thread overview]
Message-ID: <4332AEFF.1040105@cosmosbay.com> (raw)
In-Reply-To: <20050922125724.GJ26520@sunbeam.de.gnumonks.org>
Harald Welte a écrit :
> On Wed, Sep 21, 2005 at 11:29:13PM +0200, Eric Dumazet wrote:
>
>>Patch 1/3
>>
>>1) No more one rwlock_t protecting the 'curtain'
>
>
> I have no problem with this change "per se", but with the
> implementation.
>
> As of now, we live without any ugly #ifdef CONFIG_SMP / #endif sections
> in the code - and if possible, I would continue this good tradition.
>
> For example the get_counters() function. Wouldn't all the smp specific
> code (for_each_cpu(), ...) be #defined to nothing anyway?
Well... not exactly, but you are right only the first loop (SET_COUNTER) will
really do something. The if (cpu == curcpu) will be true but the compiler wont
know that, cpu and curcpu are still C variables.
>
> And if we really need the #ifdef's, I would appreciate if those
> sectionas are as small as possible. in get_counters() the section can
> definitely be smaller, rather than basically having the whole function
> body separate for smp and non-smp cases.
get_counters() is not critical, so I agree with you we can stick the general
version (not the UP optimized one)
>
> Also, how much would we loose in runtime performance if we were using a
> "rwlock_t *" even in the UP case?. I mean, it's just one more pointer
> dereference of something that is expected to be in cache anyway, isn't
> it? This gets rid of another huge set of #ifdefs that make the code
> unreadable and prone to errors being introduced later on.
>
Well, in UP case, the rwlock_t is a nulldef.
I was inspired by another use of percpu data in include/linux/genhd.h
#ifdef CONFIG_SMP
struct disk_stats *dkstats;
#else
struct disk_stats dkstats;
#endif
But if you dislike this, we can use pointer for all cases.
Eric
next prev parent reply other threads:[~2005-09-22 13:17 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-19 17:09 [PATCH, netfilter] NUMA aware ipv4/netfilter/ip_tables.c Eric dumazet
2005-09-19 17:20 ` Eric Dumazet
2005-09-19 17:48 ` Andi Kleen
2005-09-19 19:09 ` Eric Dumazet
2005-09-20 9:47 ` Eric Dumazet
2005-09-20 16:30 ` Andi Kleen
2005-09-20 17:02 ` Eric Dumazet
2005-09-20 21:45 ` [PATCH] Adds sys_set_mempolicy() in include/linux/syscalls.h , " Eric Dumazet
2005-09-20 21:45 ` Eric Dumazet
2005-09-20 21:46 ` [PATCH] Adds sys_set_mempolicy() in include/linux/syscalls.h Eric Dumazet
2005-09-21 21:24 ` [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance Eric Dumazet
2005-09-21 22:43 ` Christoph Lameter
2005-09-22 0:34 ` David S. Miller
2005-09-22 0:34 ` David S. Miller
2005-09-22 1:44 ` Christoph Lameter
2005-09-22 12:11 ` Eric Dumazet
2005-09-22 12:11 ` Eric Dumazet
2005-09-22 12:49 ` Christoph Hellwig
2005-09-22 12:54 ` Andi Kleen
2005-09-22 12:58 ` Christoph Hellwig
2005-09-22 13:05 ` Andi Kleen
2005-09-22 15:37 ` Christoph Lameter
2005-09-22 15:50 ` Eric Dumazet
2005-09-22 15:50 ` Eric Dumazet
2005-09-22 15:55 ` Christoph Lameter
2005-09-23 17:11 ` Harald Welte
2005-09-23 17:44 ` Christoph Lameter
2005-09-23 18:04 ` Dave Hansen
2005-09-26 17:58 ` vmalloc_node Christoph Lameter
2005-09-26 18:10 ` vmalloc_node Dave Hansen
2005-09-23 17:47 ` [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance Eric Dumazet
2005-09-23 18:00 ` Kyle Moffett
2005-09-22 4:18 ` James Morris
2005-09-22 4:18 ` James Morris
2005-09-22 5:07 ` Eric Dumazet
2005-09-22 13:03 ` Andi Kleen
2005-09-22 13:30 ` Eric Dumazet
2005-09-23 17:09 ` Harald Welte
2005-09-27 16:23 ` Andi Kleen
2005-09-28 0:25 ` Henrik Nordstrom
2005-09-28 8:32 ` Harald Welte
2005-09-28 8:32 ` Harald Welte
2005-09-28 8:37 ` Andi Kleen
2005-09-28 8:37 ` Andi Kleen
2005-10-04 17:01 ` Patrick McHardy
2005-10-05 16:53 ` Andi Kleen
2005-10-07 2:38 ` Harald Welte
2005-10-06 17:59 ` Andi Kleen
2005-10-07 17:08 ` Patrick McHardy
2005-10-07 17:21 ` Andi Kleen
2005-10-07 17:50 ` Patrick McHardy
2005-09-28 10:34 ` Henrik Nordstrom
2005-09-28 10:34 ` Henrik Nordstrom
2005-11-25 11:23 ` [PATCH] netfilter : zap get_cpu()/put_cpu() calls from ip_tables Eric Dumazet
2005-11-25 11:28 ` [PATCH (resent with the attachment !)] " Eric Dumazet
2005-11-25 18:20 ` Patrick McHardy
2005-09-21 21:29 ` [PATCH 1/3] netfilter : 3 patches to boost ip_tables performance Eric Dumazet
2005-09-22 12:57 ` Harald Welte
2005-09-22 12:57 ` Harald Welte
2005-09-22 13:17 ` Eric Dumazet [this message]
2005-09-22 13:17 ` Eric Dumazet
2005-09-21 21:32 ` [PATCH 2/3] " Eric Dumazet
2005-09-22 12:48 ` Harald Welte
2005-09-22 12:48 ` Harald Welte
2005-09-22 13:05 ` Eric Dumazet
2005-09-23 4:02 ` Willy Tarreau
2005-09-23 5:14 ` Eric Dumazet
2005-09-23 11:33 ` Willy Tarreau
2005-09-23 14:00 ` Tim Mattox
2005-09-21 21:37 ` [PATCH 3/3] " Eric Dumazet
2005-09-22 12:50 ` Harald Welte
2005-09-22 12:50 ` Harald Welte
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=4332AEFF.1040105@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=ak@suse.de \
--cc=laforge@netfilter.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@lists.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.