From: Holger Eitzenberger <holger@eitzenberger.org>
To: netfilter-devel@vger.kernel.org
Subject: [PATCH v2 0/3] NFQUEUE: introduce CPU fanout
Date: Sat, 23 Mar 2013 21:04:02 +0100 [thread overview]
Message-ID: <20130323200402.209591997@eitzenberger.org> (raw)
Hi,
this is v2 of the patchset which tries to improve NFQUEUE performance
if the --queue-balance argument is used for steering packets to
several NFQUEUEs. By changing the way which NFQUEUE is assigned
I'm able to improve the performance if the processes reading on the
NFQUEUs are pinned correctly.
Changes from v1:
* 1/3: fold 'flags' into 'bypass'. Not sure whether I like it.
* 2/3: tailing 'else' avoided in nfqueue_hash().
* 2/3: tried to avoid indentation uglyness in nfqueue_hash().
Current NFQUEUE target uses a hash, computed over source and
destination address (and other parameters), for steering the packet
to the actual NFQUEUE. This however forgets about the fact that the
packet eventually is handled by a particular CPU on user request.
If e. g.
1) IRQ affinity is used to handle packets on a particular CPU already
(both single-queue or multi-queue case)
and/or
2) RPS is used to steer packets to a specific softirq
the target easily chooses an NFQUEUE which is not handled by a process
pinned to the same CPU.
The idea is therefore to use the CPU index for determining the
NFQUEUE handling the packet.
E. g. when having a system with 4 CPUs, 4 MQ queues and 4 NFQUEUEs it
looks like this:
+-----+ +-----+ +-----+ +-----+
|NFQ#0| |NFQ#1| |NFQ#2| |NFQ#3|
+-----+ +-----+ +-----+ +-----+
^ ^ ^ ^
| |NFQUEUE | |
+ + + +
+-----+ +-----+ +-----+ +-----+
|rx-0 | |rx-1 | |rx-2 | |rx-3 |
+-----+ +-----+ +-----+ +-----+
The NFQUEUEs not necessarily have to start with number 0, setups with
less NFQUEUEs than packet-handling CPUs are not a problem as well.
The first patch extends the NFQUEUE target to accept a new
NFQ_FLAG_CPU_FANOUT flag. If this is specified the target uses the
CPU index for determining the NFQUEUE being used. I have to introduce
rev3 for this, sorry.
The 2nd patch coalesces rev1 and rev3 hashing by introducing
nfqueue_hash(), then used in both revisions.
The 3rd patch extends iptables userspace to accept the
--queue-cpu-fanout argument, needs --queue-balance.
Thank you.
/Holger
next reply other threads:[~2013-03-23 20:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-23 20:04 Holger Eitzenberger [this message]
2013-03-23 20:04 ` [PATCH v2 1/3] NFQUEUE: introduce CPU fanout Holger Eitzenberger
2013-04-01 23:26 ` Pablo Neira Ayuso
2013-03-23 20:04 ` [PATCH v2 2/3] NFQUEUE: coalesce IPv4 and IPv6 hashing Holger Eitzenberger
2013-04-01 23:26 ` Pablo Neira Ayuso
2013-03-23 20:04 ` [PATCH v2 3/3] NFQUEUE: add --queue-cpu-fanout parameter Holger Eitzenberger
2013-04-01 23:29 ` Pablo Neira Ayuso
2013-04-02 10:35 ` Holger Eitzenberger
2013-04-02 11:26 ` Pablo Neira Ayuso
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=20130323200402.209591997@eitzenberger.org \
--to=holger@eitzenberger.org \
--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.