From: Marco Berizzi <pupilla@libero.it>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: software interrupts close to 100 with 9000 tc filter entries
Date: Tue, 19 Sep 2017 16:57:25 +0200 (CEST) [thread overview]
Message-ID: <1518962327.463216.1505833045557@mail.libero.it> (raw)
In-Reply-To: <1505829713.29839.57.camel@edumazet-glaptop3.roam.corp.google.com>
> Eric Dumazet wrote:
>
> On Tue, 2017-09-19 at 15:28 +0200, Marco Berizzi wrote:
>
> > Hi Folks,
> >
> > I'm running linux 4.12.10 x86_64 on a Slackware 14.2 64bit
> > as a simple 4 NIC router. Network throughput processed by
> > this machine is less than 200Mbit/s
> > The cpu model is Intel(R) Xeon(R) CPU 5160 @ 3.00GHz with
> > 2GB ram.
> >
> > I need to blacklist about 9000 single ip addresses.
> > This is the relevant script to blacklist these ip addresses:
> >
> > tc qdisc add dev eth0 ingress
> > tc qdisc add dev eth1 ingress
> >
> > while read -r line
> > do
> > tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match ip src $line action drop
> > tc filter add dev eth1 parent ffff: protocol ip prio 50 u32 match ip src $line action drop
> > done < blacklisted_ip_addresses
> >
> > After loading these ip addresses, the si (software interrupts)
> > number shown by top is always close to 100
> > If I delete the ingress qdisc on both the device, the si
> > fall down to less than 5
> >
> > Running the same script with 'only' 700 ip addresses is
> > flawless.
> >
> > Kindly I would like to ask if am I doing anything in
> > a wrong way or if the hardware is too old for this kind
> > of setup.
> >
> > I have selected the tc filter setup instead of netfilter
> > one, because I was reading this from iproute2/doc/actions:
> >
> > A side effect is that we can now get stateless firewalling to work with tc..
> > Essentially this is now an alternative to iptables.
> > I wont go into details of my dislike for iptables at times, but.
> > scalability is one of the main issues; however, if you need stateful
> > classification - use netfilter (for now).
> >
> > Any response are welcome
> > TIA
>
> Processing a list of 700 rules per incoming packet is not wise.
>
> Alternatives :
>
> * netfilter with IPSET : This probably can be done with one lookup in a
> table. Probably easiest way to setup.
>
> * BPF filter (XDP or TC )
Thanks Eric for the quick response.
For better performance (latency time and network throughput) which is the better
solution? netfilter with ipset or BPF?
prev parent reply other threads:[~2017-09-19 14:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-19 13:28 software interrupts close to 100 with 9000 tc filter entries Marco Berizzi
2017-09-19 14:01 ` Eric Dumazet
2017-09-19 14:57 ` Marco Berizzi [this message]
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=1518962327.463216.1505833045557@mail.libero.it \
--to=pupilla@libero.it \
--cc=eric.dumazet@gmail.com \
--cc=netdev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox