[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201007311130.17000.arnd@arndb.de>
Date: Sat, 31 Jul 2010 11:30:16 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Shirley Ma <mashirle@...ibm.com>
Cc: "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.
On Friday 30 July 2010 17:51:52 Shirley Ma wrote:
> On Fri, 2010-07-30 at 16:53 +0800, Xin, Xiaohui wrote:
> > >Since vhost-net already supports macvtap/tun backends, do you think
> > >whether it's better to implement zero copy in macvtap/tun than
> > inducing
> > >a new media passthrough device here?
> > >
> >
> > I'm not sure if there will be more duplicated code in the kernel.
>
> I think it should be less duplicated code in the kernel if we use
> macvtap to support what media passthrough driver here. Since macvtap has
> support virtio_net head and offloading already, the only missing func is
> zero copy. Also QEMU supports macvtap, we just need add a zero copy flag
> in option.
Yes, I fully agree and that was one of the intended directions for
macvtap to start with. Thank you so much for following up on that,
I've long been planning to work on macvtap zero-copy myself but it's
now lower on my priorities, so it's good to hear that you made progress
on it, even if there are still performance issues.
Arnd
--
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