lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5172ACCB.9050203@mojatatu.com>
Date:	Sat, 20 Apr 2013 10:57:15 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Daniel Borkmann <dborkman@...hat.com>
CC:	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)

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ