On Wed, Aug 12, 2009 at 04:27:44PM -0400, Gregory Haskins wrote:
Michael S. Tsirkin wrote:
This adds support for vhost-net virtio kernel backend.
This is RFC, but works without issues for me.
Still needs to be split up, tested and benchmarked properly,
but posting it here in case
On Wed, Aug 12, 2009 at 10:48:21AM -0700, Ira W. Snyder wrote:
On Wed, Aug 12, 2009 at 08:31:04PM +0300, Michael S. Tsirkin wrote:
On Wed, Aug 12, 2009 at 10:19:22AM -0700, Ira W. Snyder wrote:
[ snip out code ]
We discussed this before, and I still think this could be directly
On Wed, Aug 12, 2009 at 07:59:47PM +0200, Arnd Bergmann wrote:
The trick is to swap the virtqueues instead. virtio-net is actually
mostly symmetric in just the same way that the physical wires on a
twisted pair ethernet are symmetric (I like how that analogy fits).
You need to really squint
On Wed, Aug 12, 2009 at 02:18:20PM -0500, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
On
Why bother switching to userspace for migration? Can't you just have
get/set ioctls for the state?
I have these. But live migration requires dirty page logging.
I do not want to
On Wed, Aug 12, 2009 at 02:27:31PM -0500, Anthony Liguori wrote:
Arnd Bergmann wrote:
As I pointed out earlier, most code in virtio net is asymmetrical: guest
provides buffers, host consumes them. Possibly, one could use virtio
rings in a symmetrical way, but support of existing guest virtio
On Wed, Aug 12, 2009 at 02:22:38PM -0500, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
We discussed this before, and I still think this could be directly derived
from struct virtqueue, in the same way that vring_virtqueue is derived from
struct virtqueue.
I prefer keeping it
This adds support for vhost-net virtio kernel backend.
This is RFC, but works without issues for me.
Still needs to be split up, tested and benchmarked properly,
but posting it here in case people want to test drive
the kernel bits I posted.
Changes since v1:
- rebased on top of
virtio-pci depends, and will always depend, on pci.c
so it makes sense to keep it in the same makefile,
(unlike the rest of virtio files which should eventually
be moved out to Makefile.hw).
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Makefile.hw |2 +-
Makefile.target |2
devices should have the final say over which virtio features they
support. E.g. indirect entries may or may not make sense in the context
of virtio-console. Move the common bits from virtio-pci to an inline
function and let each device call it.
No functional changes.
Signed-off-by: Michael S.
This adds support for vhost-net virtio kernel backend.
To enable (assuming device eth2):
1. enable promisc mode or program guest mac in device eth2
2. disable tso, gso, lro on the card
3. add vhost=eth0 to -net flag
4. run with CAP_NET_ADMIN priviledge (e.g. root)
This patch is RFC, but works
On 08/13/2009 09:15 AM, Michael S. Tsirkin wrote:
I wonder though if mmu notifiers can be used to make it transparent...
Maybe they can, but that decision belongs to KVM.
Avi, what do you think?
I don't see how mmu notifiers help. You can use mmu notifiers to sync
an external
On Thu, Aug 13, 2009 at 12:28:52PM +0300, Avi Kivity wrote:
On 08/13/2009 09:15 AM, Michael S. Tsirkin wrote:
I wonder though if mmu notifiers can be used to make it transparent...
Maybe they can, but that decision belongs to KVM.
Avi, what do you think?
I don't see how mmu
Michael S. Tsirkin wrote:
On Wed, Aug 12, 2009 at 04:27:44PM -0400, Gregory Haskins wrote:
Michael S. Tsirkin wrote:
This adds support for vhost-net virtio kernel backend.
This is RFC, but works without issues for me.
Still needs to be split up, tested and benchmarked properly,
but posting
On Thu, Aug 13, 2009 at 07:35:52AM -0400, Gregory Haskins wrote:
Michael S. Tsirkin wrote:
On Wed, Aug 12, 2009 at 04:27:44PM -0400, Gregory Haskins wrote:
Michael S. Tsirkin wrote:
This adds support for vhost-net virtio kernel backend.
This is RFC, but works without issues for me.
On Wednesday 12 August 2009, Anthony Liguori wrote:
At any rate, I'd like to see performance results before we consider
trying to reuse virtio code.
Yes, I agree. I'd also like to do more work on the macvlan extensions
to see if it works out without involving a socket. Passing the socket
into
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
On Wed, Aug 12, 2009 at 07:59:47PM +0200, Arnd Bergmann wrote:
The trick is to swap the virtqueues instead. virtio-net is actually
mostly symmetric in just the same way that the physical wires on a
twisted pair ethernet are symmetric (I
On Thu, Aug 13, 2009 at 03:48:35PM +0200, Arnd Bergmann wrote:
On Thursday 13 August 2009, Arnd Bergmann wrote:
Unfortunately, this also implies that you could no longer simply use the
packet socket interface as you do currently, as I realized only now.
This obviously has a significant
On Thu, Aug 13, 2009 at 03:38:43PM +0200, Arnd Bergmann wrote:
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
On Wed, Aug 12, 2009 at 07:59:47PM +0200, Arnd Bergmann wrote:
The trick is to swap the virtqueues instead. virtio-net is actually
mostly symmetric in just the same way
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
The best way to do this IMO would be to add zero copy support to raw
sockets, vhost will then get it basically for free.
Yes, that would be nice. I wonder if that could lead to security
problems on TX though. I guess It will only bring
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
Right now, the number of copy operations in your code is the same.
You are doing the copy a little bit later in skb_copy_datagram_iovec(),
which is indeed a very nice hack. Changing to a virtqueue based method
would imply that the host
On Thu, Aug 13, 2009 at 04:58:06PM +0200, Arnd Bergmann wrote:
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
Right now, the number of copy operations in your code is the same.
You are doing the copy a little bit later in skb_copy_datagram_iovec(),
which is indeed a very nice
On 08/13/2009 05:53 PM, Arnd Bergmann wrote:
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
The best way to do this IMO would be to add zero copy support to raw
sockets, vhost will then get it basically for free.
Yes, that would be nice. I wonder if that could lead to
On Thursday 13 August 2009, Fischer, Anna wrote:
This patch adds a 'hairpin' (also called 'reflective relay') mode
port configuration to the Linux Ethernet bridge kernel module.
A bridge supporting hairpin forwarding mode can send frames back
out through the port the frame was received on.
This patch adds a 'hairpin' (also called 'reflective relay') mode
port configuration to the Linux Ethernet bridge utilities.
A bridge supporting hairpin forwarding mode can send frames back
out through the port the frame was received on.
Hairpin mode is required to support basic VEPA (Virtual
This patch adds a 'hairpin' (also called 'reflective relay') mode
port configuration to the Linux Ethernet bridge kernel module.
A bridge supporting hairpin forwarding mode can send frames back
out through the port the frame was received on.
Hairpin mode is required to support basic VEPA (Virtual
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index eb404dc..e486f1f 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -256,6 +256,7 @@ static struct net_bridge_port *new_nbp(struct net_bridge
*br,
p-path_cost = port_cost(dev);
p-priority = 0x8000
This implements vhost: a kernel-level backend for virtio,
The main motivation for this work is to reduce virtualization
overhead for virtio by removing system calls on data path,
without guest changes. For virtio-net, this removes up to
4 system calls per packet: vm exit for kick, reentry for
vhost net module wants to do copy to/from user from a kernel thread,
which needs use_mm (like what fs/aio has). Move that into mm/ and
export to modules.
Acked-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
fs/aio.c| 47
What it is: vhost net is a character device that can be used to reduce
the number of system calls involved in virtio networking.
Existing virtio net code is used in the guest without modification.
There's similarity with vringfd, with some differences and reduced scope
- uses eventfd for
On Wed, Aug 12, 2009 at 08:31:04PM +0300, Michael S. Tsirkin wrote:
On Wed, Aug 12, 2009 at 10:19:22AM -0700, Ira W. Snyder wrote:
[ snip out code ]
We discussed this before, and I still think this could be directly derived
from struct virtqueue, in the same way that vring_virtqueue
On Wed, Aug 12, 2009 at 07:03:22PM +0200, Arnd Bergmann wrote:
On Monday 10 August 2009, Michael S. Tsirkin wrote:
+struct workqueue_struct *vhost_workqueue;
[nitpicking] This could be static.
+/* The virtqueue structure describes a queue attached to a device. */
+struct
Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support
On Tuesday 11 August 2009, Paul Congdon (UC Davis) wrote:
The patch from Eric Biederman to allow macvlan to bridge between
its slave ports is at
http://kerneltrap.org/mailarchive/linux-netdev/2009/3/9/5125774
From: Fischer, Anna anna.fisc...@hp.com
Date: Thu, 13 Aug 2009 16:55:16 +
This patch adds a 'hairpin' (also called 'reflective relay') mode
port configuration to the Linux Ethernet bridge kernel module.
A bridge supporting hairpin forwarding mode can send frames back
out through the port
33 matches
Mail list logo
