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

[Anthony Liguori <aliguori@us.ibm.com>]

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) {
}

verses

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.

-- 
Regards,

Anthony Liguori