PF_ring and friends: Options for making Linux suck less when capturing packets
Dave Taht
dave.taht at gmail.com
Wed Oct 19 12:44:08 EDT 2011
Currently I can do tcpdump -i eth1 -s 200 -w /some/usb/stick.cap at about
1.2 - 2MB/sec before saturating cpu on the wndr3700v2. (MB =megabyte)
I can r/w a usb stick at about 8/7 MB/sec. I haven' tried a 'real' hard
disk.
About 50Mbit/sec I figure covers the 95 percentile of most home users to
their ISP. 100Mbit would be better. Being drop-free would be really helpful
on shorter tests....
I was also thinking about an in-kernel module that uses 'splice' to send the
data to a file... as well as the current jit work for bpf, using netfilter,
and various other alternatives.
Or writing something in a iptables or tc filter to track things more sanely
that web100 does....
Ideas?
---------- Forwarded message ----------
From: Fabian Schneider <fabian at ieee.org>
Date: Wed, Oct 19, 2011 at 6:03 PM
Subject: Options for making Linux suck less when capturing packets
To: Dave Täht <dave.taht at gmail.com>
Cc: Ahlem Reggani
Hi Dave,
as promised here are some pointers.
- http://www.ntop.org/products/pf_ring/
- And i think that libpcap since version 1.0 has builtin support for memory
mapping, which was propose by Phil Woods [1].
- It might be worthwhile to check if the NIC supports any sort of interrupt
coalescing or polling, instead of standard one interrupt per packet.
- I have to search a bit more for the code of my student (I changed
employers twice since then).
best
Fabian
[1] http://public.lanl.gov/cpw/ramblings.html
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat-devel/attachments/20111019/a74feef7/attachment-0002.html>
More information about the Bloat-devel
mailing list