public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Xin Xiaohui <xiaohui.xin@intel.com>
Cc: netdev@vger.kernel.org, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, mingo@elte.hu, mst@redhat.com,
	jdike@c2.user-mode-linux.org
Subject: Re: [PATCH 0/3] Provide a zero-copy method on KVM virtio-net.
Date: Wed, 10 Feb 2010 14:40:04 +0100	[thread overview]
Message-ID: <201002101440.05063.arnd@arndb.de> (raw)
In-Reply-To: <1265802540-6122-1-git-send-email-xiaohui.xin@intel.com>

On Wednesday 10 February 2010, Xin Xiaohui wrote:
> The idea is simple, just to pin the guest VM user space and then
> let host NIC driver has the chance to directly DMA to it. 
> The patches are based on vhost-net backend driver. We add a device
> which provides proto_ops as sendmsg/recvmsg to vhost-net to
> send/recv directly to/from the NIC driver. KVM guest who use the
> vhost-net backend may bind any ethX interface in the host side to
> get copyless data transfer thru guest virtio-net frontend.
> 
> We provide multiple submits and asynchronous notifiicaton to 
> vhost-net too.

This does a lot of things that I had planned for macvtap. It's
great to hear that you have made this much progress.

However, I'd hope that we could combine this with the macvtap driver,
which would give us zero-copy transfer capability both with and
without vhost, as well as (tx at least) when using multiple guests
on a macvlan setup.

For transmit, it should be fairly straightforward to hook up
your zero-copy method and the vhost-net interface into the
macvtap driver.

You have simplified the receiv path significantly by assuming
that the entire netdev can receive into a single guest, right?
I'm assuming that the idea is to allow VMDq adapters to simply
show up as separate adapters and have the driver handle this
in a hardware specific way.
My plan for this was to instead move support for VMDq into the
macvlan driver so we can transparently use VMDq on hardware where
available, including zero-copy receives, but fall back to software
operation on non-VMDq hardware.

	Arnd

  parent reply	other threads:[~2010-02-10 13:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-10 11:48 [PATCH 0/3] Provide a zero-copy method on KVM virtio-net Xin Xiaohui
2010-02-10 11:48 ` [PATCH 1/3] A device for zero-copy based " Xin Xiaohui
2010-02-10 11:48   ` [PATCH 2/3] Provides multiple submits and asynchronous notifications Xin Xiaohui
2010-02-10 11:49     ` [PATCH 3/3] Let host NIC driver to DMA to guest user space Xin Xiaohui
2010-02-10 15:17   ` [PATCH 1/3] A device for zero-copy based on KVM virtio-net Eric Dumazet
2010-02-11  5:33     ` Xin, Xiaohui
2010-02-10 13:40 ` Arnd Bergmann [this message]
2010-02-11  7:40   ` [PATCH 0/3] Provide a zero-copy method " Xin, Xiaohui
2010-02-11 13:25     ` Arnd Bergmann
2010-02-11  8:54 ` Xin, Xiaohui

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=201002101440.05063.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=jdike@c2.user-mode-linux.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=xiaohui.xin@intel.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