From: Rusty Russell <rusty@rustcorp.com.au>
To: Arnd Bergmann <arnd@arndb.de>
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: Thu, 19 Feb 2009 21:26:42 +1030 [thread overview]
Message-ID: <200902192126.43174.rusty@rustcorp.com.au> (raw)
In-Reply-To: <200902181724.07655.arnd@arndb.de>
On Thursday 19 February 2009 02:54:06 Arnd Bergmann wrote:
> 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.
It's possible, but you don't want routing or parsing, etc: the NIC
is just "directly" attached to the guest.
You could do it in qemu or whatever, but it would not be the kernel scheme
(netfilter/iptables).
> > 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.
Yes, I guess this should work. Even different SR-IOV adapters will simply
send to one another. I'm not sure this obviates the desire to have direct
inter-guest which is more generic though.
Thanks!
Rusty.
next prev parent reply other threads:[~2009-02-19 10:56 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
2009-02-19 10:56 ` Rusty Russell [this message]
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=200902192126.43174.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=arnd@arndb.de \
--cc=chrisw@sous-sol.org \
--cc=herbert@gondor.apana.org.au \
--cc=kvm@vger.kernel.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.