[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1280941745.3391.15.camel@localhost.localdomain>
Date: Wed, 04 Aug 2010 10:09:05 -0700
From: Shirley Ma <mashirle@...ibm.com>
To: "Dong, Eddie" <eddie.dong@...el.com>
Cc: Arnd Bergmann <arnd@...db.de>,
"Xin, Xiaohui" <xiaohui.xin@...el.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"mst@...hat.com" <mst@...hat.com>, "mingo@...e.hu" <mingo@...e.hu>,
"davem@...emloft.net" <davem@...emloft.net>,
"herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
"jdike@...ux.intel.com" <jdike@...ux.intel.com>
Subject: RE: [RFC PATCH v8 00/16] Provide a zero-copy method on KVM
virtio-net.
Hello Eddie,
On Wed, 2010-08-04 at 10:06 +0800, Dong, Eddie wrote:
> But zero-copy is a Linux generic feature that can be used by other
> VMMs as well if the BE service drivers want to incorporate. If we can
> make mp device VMM-agnostic (it may be not yet in current patch), that
> will help Linux more.
First other VMMs support tun/tap which provides most funcs but not zero
copy.
Second mp patch only supports zero copy for vhost now, macvtap zero copy
will not be used by vhost only.
Third, the current mp device doesn't fallback to copy when failure.
So you can extend mp device to support all funcs, but the usage/funcs
will be similar with macvtap, then either mp device will replace macvtap
in the future with similar funcs or we can use enhance macvtap to
support zero copy. It is not necessary to have both in Linux.
I think it's better to implement zero copy in macvtap, tun/tap instead
of creating a new mp device.
Thanks
Shirley
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists