General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Luigi Rizzo <rizzo@iet.unipi.it>
To: bloat@lists.bufferbloat.net
Subject: [Bloat] high speed networking from userspace
Date: Tue, 13 Mar 2012 15:29:35 +0100	[thread overview]
Message-ID: <20120313142935.GA61527@onelab2.iet.unipi.it> (raw)

Hi,
Dave mentioned me the thread about netmap on this list, to which
i just subscribed.

Some of the posts are referring to Van Jacobson's "network channels"
and to previous experiments or implementations dating back to 2006 e.g.

	http://www.ioremap.net/taxonomy/term/6

I am glad to see that there were previous attempts at addressing the
problem. However before dismissing things as 'done before'
i would suggest some performance comparison.

For netmap what i can offer at the moment is some data comparing
raw packet I/O performance with various sockets families,
libpcap, PACKET_TX_RING on linux, and even the in-kernel
packet generator in Linux. See for instance see a recent ACM Queue
paper (freely accessible), fig.4 and 5

        http://queue.acm.org/detail.cfm?id=2103536

In all these cases netmap is one order of magnitude or more
faster than the alternatives.

Unfortunately I cannot find any actual performance data on netchannel
except those from the LCA'06 Van Jacobson slides, where they show
about 2x speedup over the host stack. The original
netchannel site reports 404 on all links, e.g.

        http://tservice.net.ru/~s0mbre/blog/2006/10/26#2006_10_26

If someone had some performance data or examples of technologies
that work well i would be grateful to see them.

Comparing netmap with VJ network channels:
- both try to remove skbuf, and move processing out of the
  interrupt/kernel bottom half and into the user thread (above or
  below the userland/kernel barrier) to improve cache locality and
  for other good reasons.

  These two are key ideas for improving performance, which for instance
  PF_PACKET does not use (convenient as it does not need
  driver modifications, but there is a huge cost in performance.)

I cannot easily tell whether netchannel implements any of these features:
- userspace visible buffers (saves a memory copy and data access
  which may be helpful for packet forwarding apps where you
  only look at part of the payload)
- poll-able file descriptor (useful to build a pcap layer on
  top of the packet I/O framework)

cheers
luigi


             reply	other threads:[~2012-03-13 14:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-13 14:29 Luigi Rizzo [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-03-13  0:09 Dave Taht
2012-03-13  4:15 ` Ketan Kulkarni
2012-03-13  9:26 ` Steinar H. Gunderson
2012-03-13 12:28 ` Hagen Paul Pfeifer
2012-03-13 16:03   ` Stephen Hemminger
2012-03-13 17:39     ` Hagen Paul Pfeifer
2012-03-13 19:08     ` Luigi Rizzo
2012-03-13 19:16       ` Eric Dumazet

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

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120313142935.GA61527@onelab2.iet.unipi.it \
    --to=rizzo@iet.unipi.it \
    --cc=bloat@lists.bufferbloat.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox