From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9C48D200620 for ; Wed, 19 Oct 2011 09:44:10 -0700 (PDT) Received: by vws13 with SMTP id 13so2396227vws.16 for ; Wed, 19 Oct 2011 09:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=JWWRaGQagG62yc178qWQh4KH8x3dvoRFQdKKFtFsYKk=; b=RH/OqK+nAuj+jP0dtz2WGL7FVdqSdtK1ggS/wjYg2qtF7obrHeHMSJRAi6uj1uJs2C L787V82sApcMWmUyZUdeRmFcAYsSnLFIpZ21vuzzJuyavtfmtzQGn9tOqDshQo8MZrAT m87COSC3ix/lAWI+hvX6W5VIsvNpymGwqsUjA= MIME-Version: 1.0 Received: by 10.182.131.34 with SMTP id oj2mr1128501obb.71.1319042648872; Wed, 19 Oct 2011 09:44:08 -0700 (PDT) Received: by 10.182.231.2 with HTTP; Wed, 19 Oct 2011 09:44:08 -0700 (PDT) Date: Wed, 19 Oct 2011 18:44:08 +0200 Message-ID: Subject: PF_ring and friends: Options for making Linux suck less when capturing packets From: Dave Taht To: bloat-devel , Rick Jones Content-Type: multipart/alternative; boundary=e89a8f64791b87970204afa98c78 X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 16:44:10 -0000 --e89a8f64791b87970204afa98c78 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 =3Dmegabyte) 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 th= e 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 Date: Wed, Oct 19, 2011 at 6:03 PM Subject: Options for making Linux suck less when capturing packets To: Dave T=E4ht 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 --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net --e89a8f64791b87970204afa98c78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Currently I can do tcpdump -i eth1 -s 200 -w /some/usb/stick.cap at abo= ut 1.2 - 2MB/sec before saturating cpu on the wndr3700v2. (MB =3Dmegabyte)<= br>
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 t= o their ISP. 100Mbit would be better. Being drop-free would be really helpf= ul on shorter tests....

I was also thinking about an in-kernel modul= e that uses 'splice' to send the data to a file... as well as=A0 th= e current jit work for bpf, using netfilter, and various other alternatives= .

Or writing something in a iptables or tc filter to track things more sa= nely 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 suc= k less when capturing packets
To: Dave T=E4ht <dave.taht@gmail.com>
Cc: Ahlem Reggani

<= br>
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 employe= rs twice since then).

best
Fabian

[1] http://public.lanl.gov/cpw/ramblings.html


<= br>--
Dave T=E4ht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Te= l: 0638645374
http://www.bufferb= loat.net
--e89a8f64791b87970204afa98c78--