All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Or Gerlitz <ogerlitz@Voltaire.com>,
	Jamie Lokier <jamie@shareable.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	qemu-devel@nongnu.org, Jan Kiszka <jan.kiszka@web.de>,
	Mark McLoughlin <markmc@redhat.com>, Dor Laor <dlaor@redhat.com>,
	netdev@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH] net: add raw backend  - some performance measurements
Date: Tue, 21 Jul 2009 13:27:33 +0300	[thread overview]
Message-ID: <20090721102733.GB22155@redhat.com> (raw)
In-Reply-To: <20090721072546.GA16131@gondor.apana.org.au>

On Tue, Jul 21, 2009 at 03:25:46PM +0800, Herbert Xu wrote:
> On Tue, Jul 21, 2009 at 10:03:00AM +0300, Or Gerlitz wrote:
> > 
> > okay, when setting net.bridge.bridge-nf-call-iptables to zero, the VM TX / tap+bridge packet rate climbs from 170K to 195K but it still way beyond the 240K rate achieved by the raw mode --> we have now a clear sign on the performance gain this approach provides. 
> 
> I find this hard to believe this bridge sans netfilter does a
> single lookup based on the MAC address and then just passes the
> packet to the underlying driver.

One advantage that raw sockets have over tap+bridge, is that they do not
do their own TX buffering, but use the TX queue for the device directly.
With raw sockets, send will block or fail if the TX queue for device is
full. With tap+bridge, the buffer in tap has to fill up instead, which
is not the same. I'm not sure this is the issue here, but could be: the
benchmark is UDP, isn't it?


> Can you do an oprofile run to see if something else is chewing
> up CPU time under the guise of bridging?
> 
> Thanks,
> -- 
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Mark McLoughlin <markmc@redhat.com>,
	netdev@vger.kernel.org, Dor Laor <dlaor@redhat.com>,
	qemu-devel@nongnu.org, Or Gerlitz <ogerlitz@Voltaire.com>,
	Jan Kiszka <jan.kiszka@web.de>
Subject: Re: [Qemu-devel] [PATCH] net: add raw backend  - some performance measurements
Date: Tue, 21 Jul 2009 13:27:33 +0300	[thread overview]
Message-ID: <20090721102733.GB22155@redhat.com> (raw)
In-Reply-To: <20090721072546.GA16131@gondor.apana.org.au>

On Tue, Jul 21, 2009 at 03:25:46PM +0800, Herbert Xu wrote:
> On Tue, Jul 21, 2009 at 10:03:00AM +0300, Or Gerlitz wrote:
> > 
> > okay, when setting net.bridge.bridge-nf-call-iptables to zero, the VM TX / tap+bridge packet rate climbs from 170K to 195K but it still way beyond the 240K rate achieved by the raw mode --> we have now a clear sign on the performance gain this approach provides. 
> 
> I find this hard to believe this bridge sans netfilter does a
> single lookup based on the MAC address and then just passes the
> packet to the underlying driver.

One advantage that raw sockets have over tap+bridge, is that they do not
do their own TX buffering, but use the TX queue for the device directly.
With raw sockets, send will block or fail if the TX queue for device is
full. With tap+bridge, the buffer in tap has to fill up instead, which
is not the same. I'm not sure this is the issue here, but could be: the
benchmark is UDP, isn't it?


> Can you do an oprofile run to see if something else is chewing
> up CPU time under the guise of bridging?
> 
> Thanks,
> -- 
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

  parent reply	other threads:[~2009-07-21 10:28 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-01 15:46 [Qemu-devel] [PATCH] net: add raw backend Or Gerlitz
2009-07-01 16:21 ` Jamie Lokier
2009-07-02 12:25   ` Or Gerlitz
2009-07-03  2:39     ` Jamie Lokier
2009-07-07 13:33       ` Or Gerlitz
2009-07-07 14:57         ` Jamie Lokier
2009-07-08 14:45           ` Or Gerlitz
2009-07-14 13:54             ` Or Gerlitz
2009-07-15 20:38             ` Jamie Lokier
2009-07-15 21:06               ` Jan Kiszka
2009-07-15 21:52                 ` Jamie Lokier
2009-07-16  8:29               ` Or Gerlitz
2009-07-20 14:13               ` [Qemu-devel] [PATCH] net: add raw backend - some performance measurements Or Gerlitz
2009-07-20 15:53                 ` Herbert Xu
2009-07-20 18:20                   ` Michael S. Tsirkin
2009-07-21  1:46                     ` Herbert Xu
2009-07-21  7:03                   ` Or Gerlitz
2009-07-21  7:25                     ` Herbert Xu
2009-07-21  7:25                       ` Herbert Xu
2009-07-21 10:17                       ` Or Gerlitz
2009-07-21 10:17                         ` Or Gerlitz
2009-07-21 10:27                       ` Michael S. Tsirkin [this message]
2009-07-21 10:27                         ` Michael S. Tsirkin
2009-07-21 11:05                         ` Or Gerlitz
2009-07-21 11:05                           ` Or Gerlitz
2009-07-21 12:01                           ` Michael S. Tsirkin
2009-07-21 12:01                             ` Michael S. Tsirkin
2009-07-21 12:14                             ` Herbert Xu
2009-07-21 12:14                               ` Herbert Xu
2009-07-21 13:41                               ` Or Gerlitz
2009-07-21 13:41                                 ` Or Gerlitz
     [not found] ` <5b31733c0907011250i7afcdbcdnb844290de4ad64f2@mail.gmail.com>
2009-07-02 12:08   ` [Qemu-devel] [PATCH] net: add raw backend Or Gerlitz
2009-07-02 15:43 ` Michael S. Tsirkin
2009-07-07 14:45   ` Or Gerlitz
2009-07-07 14:49     ` Michael S. Tsirkin
2009-07-08 14:46       ` Or Gerlitz
2009-07-08 15:06       ` Or Gerlitz

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=20090721102733.GB22155@redhat.com \
    --to=mst@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=dlaor@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jamie@shareable.org \
    --cc=jan.kiszka@web.de \
    --cc=markmc@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=ogerlitz@Voltaire.com \
    --cc=qemu-devel@nongnu.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.