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.dk \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=shemminger@vyatta.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.