Hi Anthony, On Sat, 2008-06-14 at 18:28 -0500, Anthony Liguori wrote: > Mark McLoughlin wrote: > > Where a VLAN consists only of a single tap interface on the > > host side and a single virtio interface on the guest side, > > we can use the tun/tap driver's vringfd support to eliminate > > copies. > > > > We set up a vringfd for both rings and pass them to the > > tun/tap driver. When the guest informs us of the location of > > the ring pages, we use the VRINGSETINFO ioctl() to inform > > the /dev/vring driver. > > > > This patch set is useful for testing (I have one too in my patch > queue).
Ah, didn't know of your queue ... Is it (http://hg.codemonkey.ws/) down atm? > We need to make some more pervasive changes to QEMU though to > take advantage of vringfd upstream. > > Specifically, we need to introduce a RX/TX buffer adding/polling API for > VLANClientState. We can then use this within a vringfd VLAN client to > push the indexes to vringfd. I don't think I'm following you fully on this. The TX side is fine - guest adds buffer to ring, virtio VLANClient calls ->add_tx_buffer() on every other VLANClient, waits until all are finished sending and notifies the guest that we're done. But the RX side? The guest allocates the buffers, so does the virtio VLANClient divide those buffers between every other VLANClient? Or does it make all buffers available to all clients and have a way of locking a buffer just before using it? The former would be a waste, and we don't have any way of doing the latter right now with vringfd. Also, since a client could be supplied with RX buffers from multiple other clients, tun/tap would need to support multiple RX rings. It really makes one wonder whether QEMU's VLAN feature is really worth all this bother. Oh yes, there's also GSO feature negotiation; you'd need to have a way of figuring out what clients support what GSO features, which is fine ... expect for what to do in the case of hotplug. > We can't use the base/limit stuff in QEMU so we have to do > translation. Not a big deal really. Yeah, that's not a problem. > Have you benchmarked the driver? I wasn't seeing great performance > myself although I think that was due to some bugs in the vringfd code. Nope, I haven't done any real benchmarking with it yet. Cheers, Mark. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
