>-----Original Message----- >From: linux-kernel-owner@xxxxxxxxxxxxxxx [mailto:linux-kernel-owner@xxxxxxxxxxxxxxx] On >Behalf Of Xin, Xiaohui >Sent: Monday, September 27, 2010 8:45 AM >To: Michael S. Tsirkin >Cc: netdev@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; >mingo@xxxxxxx; davem@xxxxxxxxxxxxx; herbert@xxxxxxxxxxxxxxxxxxxx; >jdike@xxxxxxxxxxxxxxx >Subject: RE: [PATCH v11 00/17] Provide a zero-copy method on KVM virtio-net. > >>From: Michael S. Tsirkin [mailto:mst@xxxxxxxxxx] >>Sent: Monday, September 27, 2010 1:02 AM >>To: Xin, Xiaohui >>Cc: netdev@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; >>mingo@xxxxxxx; davem@xxxxxxxxxxxxx; herbert@xxxxxxxxxxxxxxxxxxxx; >>jdike@xxxxxxxxxxxxxxx >>Subject: Re: [PATCH v11 00/17] Provide a zero-copy method on KVM virtio-net. >> >>On Sat, Sep 25, 2010 at 12:27:18PM +0800, xiaohui.xin@xxxxxxxxx wrote: >>> We provide an zero-copy method which driver side may get external >>> buffers to DMA. Here external means driver don't use kernel space >>> to allocate skb buffers. Currently the external buffer can be from >>> guest virtio-net driver. >>> >>> 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. >>> patch 01-10: net core and kernel changes. >>> patch 11-13: new device as interface to mantpulate external buffers. >>> patch 14: for vhost-net. >>> patch 15: An example on modifying NIC driver to using napi_gro_frags(). >>> patch 16: An example how to get guest buffers based on driver >>> who using napi_gro_frags(). >>> patch 17: It's a patch to address comments from Michael S. Thirkin >>> to add 2 new ioctls in mp device. >>> We split it out here to make easier reiewer. >> >> >> >>I commented on how to avoid mm semaphore on data path separately, and >>since you didn't have time to review that yet, I won't repeat that here. >> > >I think I did avoid that in data path to use mm semaphore. I stored the value >in mp structures and check with that. > Hi Michael, Did you think I have addressed your comments about to avoid mm semaphore on data path or not? I stored the value in mp structures and don't use mmap_semphore. Or you still have some concerns with it? >>At this point what are the plans on macvtap integration? >>You indicated this is the interface you intend to use longterm. > >I'm now working on that. > I'm now trying to export some functions from mp device, and let macvtap to use them for rx zero-copy. > >Thanks >Xiaohui >-- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@xxxxxxxxxxxxxxx >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
