[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH 9/9] Introduce VLANClientState::cleanup()

From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [PATCH 9/9] Introduce VLANClientState::cleanup()
Date: Tue, 28 Apr 2009 16:38:46 -0500
User-agent: Thunderbird (X11/20090320)

Paul Brook wrote:
On Tuesday 28 April 2009, Anthony Liguori wrote:
Paul Brook wrote:
Hmm, in that case I don't understand your distinction between frontend
and backend.
In the case of networking, they don't have to be distinct because all
you need to do is have two "front-ends" and flip the TX/RX queues.
Although even in this case, someone has to own the MAC address so it's
not purely symmetric.

I'm still not understanding. Ethernet devices are fundamentally based around a bus architecture. "flip the TX/RX queues" only makes sense if you're talking about a point-point connection. For ethernet devices I see no reason to distinguish between "host" devices (slirp, vde, tap) and "guest" devices. They may be created for different reasons, but they're all doing fundamentally the same thing.

In the bus model, there's an implicit copy-to-the-wire operation that results in replication of the packet to everything else on the bus. From a performance perspective, this is not at all ideal.

So really, what we're talking about is the difference between an API that consists of:

net->transmit_packet(data, size)
net_receive_packet(data, size) {


net->add_transmit_packet(data, size);
datum = net->add_receive_packet(data, size);
net_notify_received_packets(datum) {

If the device visible API implies a copy, we lack the ability to do zero-copy receive.

That's not saying we shouldn't have the VLAN mechanism in QEMU but that should sit above a network backend that would then do the necessary copying.

And yeah, that means that we cannot have the tap implementation have an identical API to the devices. This is necessary though from a performance perspective.

In the general case, that isn't always true for devices.  Consider block
devices, for instance.

You mean the API we expose to the devices v.s. the API we expose to the image file backends? Or do you mean different layers like ide/scsi v.s. internal block devices?

I mean the interface IDE/SCSI use to read/write data from a block device is not the same interface that block-qcow2 uses to provide support for qcow2 images. Your argument IIUC is that block devices are not inherently bus oriented and this is certainly true. However, I'm arguing that bus oriented APIs imply copies to the bus which is not something we want to bake into the interface.

So my example of block devices are irrelevant because I didn't understand what you originally were commenting on.


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]