From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Daniel Borkmann <dborkman@redhat.com>
Cc: David Miller <davem@davemloft.net>,
gregkh@linuxfoundation.org, stephen@networkplumber.org,
netdev@vger.kernel.org, Eric Leblond <eric@regit.org>,
Eric Dumazet <eric.dumazet@gmail.com>,
Luigi Rizzo <rizzo@iet.unipi.it>
Subject: Re: [RFC 1/2] netmap: infrastructure (in staging)
Date: Sat, 20 Apr 2013 10:57:15 -0400 [thread overview]
Message-ID: <5172ACCB.9050203@mojatatu.com> (raw)
In-Reply-To: <51727C76.6010501@redhat.com>
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).
It is true without some changes to the kernel (such as using multiqueues
and batching, pktgen will not be able to achieve that speed). It would
be interesting to see what you can achieve with PF_PACKET transmit.
PF_PACKET is already behind if you have to depend on fanout for receive
(you are using more processing).
Granted that this was a simple app. Unfortunately the trend with
approaches like netmap is happening. Theres some closed source thing out
of intel called DPDK which intel is aggressively marketing.
If someone is showing you 10x improvement over what Linux gives you,
then we are doing something wrong and we shouldnt be living in some
parallel universe and claim theres nothing to see here.
1.5-3x is something i can live with because it shows theres some room
for tweaking.
From a personal perspective - I have always been a supporter of "if
something is wrong with what linux gives you, lets improve it" (Still
grinding my teeth at openvswitch).
How about we learn something from this and try to improve what we have?
I did talk to Luigi briefly (CCing him) - his biggest beef was with skbs
and how fat they are. I know Eric D. has been doing some excellent work
putting them on some low-carb diet but there are still people showing up
and arguing for more fields. Here's a thought:
Could we put something in the kernel that allows for high-perfomance
zero copy to user space and inject packets + metadata (from/to
arbitrary parts of the kernel)? I do this all the time from say
ingress/egress via tuntap (which sucks at this).
Yes, theres a danger of allowing for competing interfaces in userspace
to develop tcp stacks etc but I think for someone who wants to take
advantage of Linux, thats a non-starter.
cheers,
jamal
next prev parent reply other threads:[~2013-04-20 14:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-19 19:06 [RFC 1/2] netmap: infrastructure (in staging) Stephen Hemminger
2013-04-19 19:09 ` [RFC 2/2] ixgbe: netmap support Stephen Hemminger
2013-04-19 19:45 ` [RFC 1/2] netmap: infrastructure (in staging) Greg KH
2013-04-19 19:58 ` David Miller
2013-04-19 20:16 ` Stephen Hemminger
2013-04-19 20:31 ` Eric Dumazet
2013-04-19 20:38 ` David Miller
2013-04-19 20:49 ` Stephen Hemminger
2013-04-19 20:53 ` David Miller
2013-05-07 17:20 ` chetan loke
2013-04-19 20:37 ` David Miller
2013-04-20 11:31 ` Daniel Borkmann
2013-04-20 14:57 ` Jamal Hadi Salim [this message]
2013-04-20 15:19 ` "Oleg A. Arkhangelsky"
2013-04-28 22:33 ` Willy Tarreau
2013-04-20 23:20 ` Vincent JARDIN
2013-04-23 7:04 ` Naoto MATSUMOTO
2013-04-23 7:10 ` David Miller
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=5172ACCB.9050203@mojatatu.com \
--to=jhs@mojatatu.com \
--cc=davem@davemloft.net \
--cc=dborkman@redhat.com \
--cc=eric.dumazet@gmail.com \
--cc=eric@regit.org \
--cc=gregkh@linuxfoundation.org \
--cc=netdev@vger.kernel.org \
--cc=rizzo@iet.unipi.it \
--cc=stephen@networkplumber.org \
/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.