Mark McLoughlin wrote:
Hi Anthony,
On Sat, 2008-06-14 at 18:28 -0500, Anthony Liguori wrote:
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?
It's up now.
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?
This is where things get tricky. Internally, it will have to copy the
TX buffer into each of the clients RX buffers. We need to special case
the circumstance where the only other VLANClientState is a vringfd
client so that we can pass the RX buffer directly to it. Haven't come
up with a perfect API just yet but that's what we need to do.
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.
It's necessary for upstream acceptance and solving the problem right
will give us vringfd support for the e1000 for free.
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.
Right, we need a feature API.
Regards,
Anthony Liguori
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
