From: Jesper Dangaard Brouer <hawk@comx•dk>
To: Eric Dumazet <eric.dumazet@gmail•com>
Cc: Stephen Hemminger <shemminger@vyatta•com>,
netfilter-devel <netfilter-devel@vger•kernel.org>,
netdev <netdev@vger•kernel.org>
Subject: Re: Possible regression: Packet drops during iptables calls
Date: Tue, 14 Dec 2010 17:09:18 +0100 [thread overview]
Message-ID: <1292342958.9155.91.camel@firesoul.comx.local> (raw)
In-Reply-To: <1292340702.5934.5.camel@edumazet-laptop>
On Tue, 2010-12-14 at 16:31 +0100, Eric Dumazet wrote:
> Le mardi 14 décembre 2010 à 15:46 +0100, Jesper Dangaard Brouer a
> écrit :
> > I'm experiencing RX packet drops during call to iptables, on my
> > production servers.
> >
> > Further investigations showed, that its only the CPU executing the
> > iptables command that experience packet drops!? Thus, a quick fix was
> > to force the iptables command to run on one of the idle CPUs (This can
> > be achieved with the "taskset" command).
> >
> > I have a 2x Xeon 5550 CPU system, thus 16 CPUs (with HT enabled). We
> > only use 8 CPUs due to a multiqueue limitation of 8 queues in the
> > 1Gbit/s NICs (82576 chips). CPUs 0 to 7 is assigned for packet
> > processing via smp_affinity.
> >
> > Can someone explain why the packet drops only occur on the CPU
> > executing the iptables command?
> >
>
> It blocks BH
>
> take a look at commits :
>
> 24b36f0193467fa727b85b4c004016a8dae999b9
> netfilter: {ip,ip6,arp}_tables: dont block bottom half more than
> necessary
>
> 001389b9581c13fe5fc357a0f89234f85af4215d
> netfilter: {ip,ip6,arp}_tables: avoid lockdep false positive
>
> for attempts to let BH fly ...
>
> Unfortunately, lockdep rules :(
Is the lockdep check a false positive?
Could I run with 24b36f0193 in production, to fix my problem?
I forgot to mention I run kernel 2.6.35.8-comx01+ (based on Greg's stable kernel tree).
$ git describe --contains 24b36f019346
v2.6.36-rc1~571^2~46^2~7
$ git describe --contains 001389b9581c1
v2.6.36-rc3~2^2~42
> > What can we do to solve this issue?
Any ideas how we can proceed?
Looking closer at the two combined code change, I see that the code path
has been improved (a bit), as the local BH is only disabled inside the
for_each_possible_cpu(cpu). Before local_bh was disabled for the hole
function. Guess I need to reproduce this in my testlab.
Thanks for your 'ninja' input ;-)
--
Med venlig hilsen / Best regards
Jesper Brouer
ComX Networks A/S
Linux Network Kernel Developer
Cand. Scient Datalog / MSc.CS
Author of http://adsl-optimizer.dk
LinkedIn: http://www.linkedin.com/in/brouer
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger•kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-12-14 16:09 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-14 14:46 Possible regression: Packet drops during iptables calls Jesper Dangaard Brouer
2010-12-14 15:31 ` Eric Dumazet
2010-12-14 16:09 ` Jesper Dangaard Brouer [this message]
2010-12-14 16:24 ` Eric Dumazet
2010-12-16 14:04 ` Jesper Dangaard Brouer
2010-12-16 14:12 ` Eric Dumazet
2010-12-16 14:24 ` Jesper Dangaard Brouer
2010-12-16 14:29 ` Eric Dumazet
2010-12-16 15:02 ` Eric Dumazet
2010-12-16 16:07 ` [PATCH net-next-2.6] netfilter: ip_tables: dont block BH while reading counters Eric Dumazet
2010-12-16 16:53 ` [PATCH v2 " Eric Dumazet
2010-12-16 17:31 ` Stephen Hemminger
2010-12-16 17:53 ` [PATCH v3 net-next-2.6] netfilter: x_tables: " Eric Dumazet
2010-12-16 17:57 ` Stephen Hemminger
2010-12-16 19:58 ` Eric Dumazet
2010-12-16 20:12 ` Stephen Hemminger
2010-12-16 20:40 ` Eric Dumazet
2010-12-16 17:57 ` Stephen Hemminger
2010-12-18 4:29 ` [PATCH v4 " Eric Dumazet
2010-12-20 13:42 ` Jesper Dangaard Brouer
2010-12-20 14:45 ` Eric Dumazet
2010-12-21 16:48 ` Jesper Dangaard Brouer
2011-01-08 16:45 ` Eric Dumazet
2011-01-09 21:31 ` Pablo Neira Ayuso
2010-12-16 14:13 ` Possible regression: Packet drops during iptables calls Eric Dumazet
2010-12-16 14:20 ` Steven Rostedt
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=1292342958.9155.91.camel@firesoul.comx.local \
--to=hawk@comx$(echo .)dk \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=netfilter-devel@vger$(echo .)kernel.org \
--cc=shemminger@vyatta$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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