PF_ring and friends: Options for making Linux suck less when capturing packets

[Dave Taht <dave.taht@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

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@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@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

[-- Attachment #2: Type: text/html, Size: 2133 bytes --]