From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Deniz Eren <denizlist@denizeren.net>
Cc: brouer@redhat.com, netdev@vger.kernel.org,
Tobias Klauser <tklauser@distanz.ch>
Subject: Re: Packet capturing performance
Date: Thu, 21 May 2015 09:25:22 +0200 [thread overview]
Message-ID: <20150521092522.3346be4e@redhat.com> (raw)
In-Reply-To: <CAHQdsZ-KmL-ksQzHni6ZbfREaZ7sumFkjh5qLwEwd+pdYWFsLw@mail.gmail.com>
On Wed, 20 May 2015 16:13:54 +0300
Deniz Eren <denizlist@denizeren.net> wrote:
> Hi,
>
> I'm having problem with packet capturing performance on my linux server.
>
> I am using Intel ixgbe 10g NIC with v3.19.1 version driver over Linux
> 3.15.9 based system. Naturally I can route 3.8Mpps packet from spoof
> (random source) addressed traffic.
>
> Whenever I open netsniff-ng to listen interface to capture packets at
> silent mode, the capturing performance slows down at the same time to
> ~1.2Mpps levels. I have doing pps measurements by watching the changes
> at "/sys/class/net/<interface_name>/statistics/rx_packets" so the
> performance can not be affected the measurements (instead of tcpstat
> etc).
Did you try to use the recently add fanout feature of netsniff-ng?
https://github.com/netsniff-ng/netsniff-ng/commit/f00d4d54f28c0
> My first theory was bpf is cause of this slowdown. When I try to
> analyze the reason of this bottleneck I see that the bpf affects the
> slow down ratio. When I narrow the filter to match 1/16 packet of
> traffic (for example: "src net 16.0.0.0/4" ), the capturing paket
> performance stay ~3.7Mpps. And I start 16 netsniff-ng process (each
> one process 1/16 part of entire traffic) with different filters the
> performance stays ~3.0Mpps and the union of the 16 filter equal to
> 0.0.0.0/0 (0.0.0.0/4 + 16.0.0.0/4 + 32.0.0.0/4 + ... + 248.0.0.0/4 =
> 0.0.0.0/0) . In other words
> I think performance of network stack slow downs dramatically after a
> number of matching traffic packets with given bpf.
>
> But after some investigation and some advice from more expert people
> the problem seems to be pf_packet sockets overhead. But I don't know
> exactly where is the bottleneck. Do you have any idea exactly where
> could be the bottleneck?
>
> Since I am using netfilter a lot, kernel bypass is not an option for me.
>
> To solve this problem I have two options for now:
>
> - First one is experimenting socket fanout and adapting my tools to
> use socket fanout.
> - Second one is somehow similar, open more than one (ex: 16) socket
> MMAP'ed socket whose have different filters from each other to match
> with different part of the traffic at single netsniff_ng process. But
> this one is too hacky and requires user-space modifications.
>
> But I want to ask is there a better solution to this problem? Am I
> missing a network tuning on linux or my ethernet device?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2015-05-21 7:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-20 13:13 Packet capturing performance Deniz Eren
2015-05-20 15:06 ` Eric Dumazet
2015-05-21 7:25 ` Jesper Dangaard Brouer [this message]
2015-07-02 6:02 ` yzhu1
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=20150521092522.3346be4e@redhat.com \
--to=brouer@redhat.com \
--cc=denizlist@denizeren.net \
--cc=netdev@vger.kernel.org \
--cc=tklauser@distanz.ch \
/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.