public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Chris Wright <chrisw@sous-sol.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	kvm@vger.kernel.org
Subject: Re: copyless virtio net thoughts?
Date: Wed, 18 Feb 2009 17:24:06 +0100	[thread overview]
Message-ID: <200902181724.07655.arnd@arndb.de> (raw)
In-Reply-To: <200902182208.00843.rusty@rustcorp.com.au>

On Wednesday 18 February 2009, Rusty Russell wrote:

> 2) Direct NIC attachment
> This is particularly interesting with SR-IOV or other multiqueue nics,
> but for boutique cases or benchmarks, could be for normal NICs.  So
> far I have some very sketched-out patches: for the attached nic 
> dev_alloc_skb() gets an skb from the guest (which supplies them via
> some kind of AIO interface), and a branch in netif_receive_skb()
> which returned it to the guest.  This bypasses all firewalling in
> the host though; we're basically having the guest process drive
> the NIC directly.       

If this is not passing the PCI device directly to the guest, but
uses your concept, wouldn't it still be possible to use the firewalling
in the host? You can always inspect the headers, drop the frame, etc
without copying the whole frame at any point.

When it gets to the point of actually giving the (real pf or sr-iov vf)
to one guest, you really get to the point where you can't do local
firewalling any more.

> 3) Direct interguest networking
> Anthony has been thinking here: vmsplice has already been mentioned.
> The idea of passing directly from one guest to another is an
> interesting one: using dma engines might be possible too.  Again,
> host can't firewall this traffic.  Simplest as a dedicated "internal
> lan" NIC, but we could theoretically do a fast-path for certain MAC
> addresses on a general guest NIC.     

Another option would be to use an SR-IOV adapter from multiple guests,
with a virtual ethernet bridge in the adapter. This moves the overhead
from the CPU to the bus and/or adapter, so it may or may not be a real
benefit depending on the workload.

	Arnd <><

  parent reply	other threads:[~2009-02-18 16:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-05  2:07 copyless virtio net thoughts? Chris Wright
2009-02-05 12:37 ` Avi Kivity
2009-02-05 14:25   ` Anthony Liguori
2009-02-06  5:40   ` Herbert Xu
2009-02-06  8:46     ` Avi Kivity
2009-02-06  9:19       ` Herbert Xu
2009-02-06 14:55         ` Avi Kivity
2009-02-07 11:56           ` Arnd Bergmann
2009-02-08  3:01             ` David Miller
2009-02-18 11:38 ` Rusty Russell
2009-02-18 12:17   ` Herbert Xu
2009-02-18 16:24   ` Arnd Bergmann [this message]
2009-02-19 10:56     ` Rusty Russell
2009-02-18 23:31   ` Simon Horman
2009-02-19  1:03     ` Dong, Eddie
2009-02-19 11:36     ` Rusty Russell
2009-02-19 14:51       ` Arnd Bergmann
2009-02-19 23:09       ` Simon Horman
2009-02-19 11:37     ` Chris Wright

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=200902181724.07655.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=chrisw@sous-sol.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=kvm@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    /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