[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130428223355.GA28736@1wt.eu>
Date: Mon, 29 Apr 2013 00:33:55 +0200
From: Willy Tarreau <w@....eu>
To: Jamal Hadi Salim <jhs@...atatu.com>
Cc: Daniel Borkmann <dborkman@...hat.com>,
David Miller <davem@...emloft.net>, gregkh@...uxfoundation.org,
stephen@...workplumber.org, netdev@...r.kernel.org,
Eric Leblond <eric@...it.org>,
Eric Dumazet <eric.dumazet@...il.com>,
Luigi Rizzo <rizzo@....unipi.it>
Subject: Re: [RFC 1/2] netmap: infrastructure (in staging)
Hi Jamal,
On Sat, Apr 20, 2013 at 10:57:15AM -0400, Jamal Hadi Salim wrote:
> On 13-04-20 07:31 AM, Daniel Borkmann wrote:
>
> >Also, I just looked over Netmap's Usenix paper from 2012, where they
> >compare netmap against pktgen, and while they state the version of the
> >FreeBSD
> >kernel
> >where they did the evaluation on, they just don't even mention the Linux'
> >kernel version, their Linux kernel setup etc. Not even mentioning a
> >comparison
> >of PF_PACKET+fanout (similarly as the PF_RING project seems to avoid this
> >comparison and only presents perf numbers where they just count packets !).
> >Also, I've seen other papers published in 2012 on this topic, where they
> >compare performance with a 2.6.2x kernel, hm, quite sad actually.
>
> I hope I can put your doubts to rest. Netmap does provide the
> performance it claims to. I did play with it about 6-9 months back and i
> was able to loopback wirerate 10Gbps (~14.4Mpps) 64B packets on a
> _single core_. i.e i send to from machine A to B which echoes back to
> the sender via a driver hack i had on the intel driver and i count the
> packets. I should note that this was with machines that have circa 2010
> capabilities (and they were cheap too).
I second this. I experimented packet filtering and generation at line rate
on a single core with netmap. This is ~28 Mpps on 2 cores. I could barely
achieve 8.8 Mpps using the all 6 cores in this machine using AF_PACKET and
mmap.
There are currently shortcomings to netmap, including the loss of the csum
information from incoming packets, and lack of support for gso/tso for outgoing
ones. I don't much like the way it bypasses the driver using netif_rx() etc...
and would prefer a design which sits between the NIC and the driver so as to
be as much transparent as possible. But for some specific usages, it can be
great. And it's true that for capturing line-rate traffic on production
systems without eating all their resources, it's nice as well.
I don't know if it's mature enough for being usable as-is in the kernel,
but I think it could get enough attention to significantly improve.
Regards,
Willy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists