netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: "Paul Congdon \(UC Davis\)" <ptcongdon@ucdavis.edu>,
	drobbins@funtoo.org, "'Fischer, Anna'" <anna.fischer@hp.com>,
	herbert@gondor.apana.org.au, mst@redhat.com,
	netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, ogerlitz@voltaire.com,
	evb@yahoogroups.com, davem@davemloft.net
Subject: Re: [Bridge] [PATCH] macvlan: add tap device backend
Date: Fri, 7 Aug 2009 23:38:57 +0200	[thread overview]
Message-ID: <200908072338.57895.arnd@arndb.de> (raw)
In-Reply-To: <20090807123554.7c2bc27c@nehalam>

On Friday 07 August 2009, Stephen Hemminger wrote:
> On Fri, 7 Aug 2009 12:10:07 -0700
> "Paul Congdon \(UC Davis\)" <ptcongdon@ucdavis.edu> wrote:
> 
> > Responding to Daniel's questions...
> > 
> > > I have some general questions about the intended use and benefits of 
> > > VEPA, from an IT perspective:
> > > 
> > > In which virtual machine setups and technologies do you forsee this 
> > > interface being used?
> > 
> > The benefit of VEPA is the coordination and unification with the
> > external network switch.  So, in environments where you are
> > needing/wanting your feature rich, wire speed, external network
> > device (firewall/switch/IPS/content-filter) to provide consistent
> > policy enforcement, and you want your VMs traffic to be subject to
> > that enforcement, you will want their traffic directed externally.
> > Perhaps you have some VMs that are on a DMZ or clustering an 
> > application or implementing a multi-tier application where you
> > would normally place a firewall in-between the tiers.
> 
> I do have to raise the point that Linux is perfectly capable of keeping up without
> the need of an external switch.  Whether you want policy external or internal is
> a architecture decision that should not be driven by mis-information about performance.

In general, I agree that Linux on a decent virtual machine host will be
able to handle forwarding of network data fast enough, often faster than
the external connectivity allows if it needs to transmit every frame twice.

However, there is a tradeoff between CPU cycles and I/O bandwidth. If your
application needs lots of CPU but you have spare capacity on the PCI bus, the
network wire and the external switch, VEPA can also be a win on the performance
side. As always, performance depends on the application, even if it's not the
main driving factor here.

	Arnd <><

  parent reply	other threads:[~2009-08-07 21:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <0199E0D51A61344794750DC57738F58E6D6A6CD7F6@GVW1118EXC.americas.hpqcorp.net>
2009-08-07 19:10 ` [Bridge] [PATCH] macvlan: add tap device backend Paul Congdon (UC Davis)
2009-08-07 19:35   ` Stephen Hemminger
2009-08-07 19:44     ` Fischer, Anna
2009-08-07 20:17       ` david
2009-08-07 19:47     ` Paul Congdon (UC Davis)
2009-08-07 21:38     ` Arnd Bergmann [this message]
2009-08-07 22:05   ` Arnd Bergmann
2009-08-10 12:40     ` Fischer, Anna
2009-08-10 19:04       ` Arnd Bergmann
2009-08-10 19:32         ` Michael S. Tsirkin
2009-08-06 21:50 Arnd Bergmann
2009-08-07 17:35 ` [Bridge] " Daniel Robbins

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=200908072338.57895.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=anna.fischer@hp.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=drobbins@funtoo.org \
    --cc=evb@yahoogroups.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=ogerlitz@voltaire.com \
    --cc=ptcongdon@ucdavis.edu \
    --cc=shemminger@vyatta.com \
    /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;
as well as URLs for NNTP newsgroup(s).