[Qemu-devel] Re: [PATCH 0/8] vlan cleanup

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 3174 bytes --]

Anthony Liguori wrote:
> On 07/13/2010 02:08 PM, Jan Kiszka wrote:
>> Anthony Liguori wrote:
>>   
>>> On 07/13/2010 07:48 AM, Jan Kiszka wrote:
>>>     
>>>> Miguel Di Ciurcio Filho wrote:
>>>>
>>>>       
>>>>> On Tue, Jul 13, 2010 at 3:16 AM, Jan Kiszka<jan.kiszka@web.de>  
>>>>> wrote:
>>>>>
>>>>>         
>>>>>> Miguel Di Ciurcio Filho wrote:
>>>>>>
>>>>>>           
>>>>>>> This series removes the vlan stuff without mercy. I've tried to
>>>>>>> make the steps
>>>>>>> as small as possible, but the last one is huge. I did some basic
>>>>>>> tests and
>>>>>>> networking is still working, so reviews are welcome :-D
>>>>>>>
>>>>>>>              
>>>>>> Sorry, this is a bit too rude. This not only removes the vlan model,
>>>>>> something one may talk about, but also the innocent socket back-ends
>>>>>> and
>>>>>> the useful pcap dump support.
>>>>>>
>>>>>> Socket back-ends allow quick and easy unprivileged inter-VM network
>>>>>> setups. Nothing for production systems, but useful for testing
>>>>>> purposes
>>>>>> on boxes where taps are not allowed or unhandy to configure.
>>>>>>
>>>>>>
>>>>>>            
>>>>> I agree that it might be handy sometimes, but one could use VDE for
>>>>> that too. Runs on user-space and can be tunneled over SSH or netcat
>>>>> [1].
>>>>>
>>>>>          
>>>> Yes, I know. But it requires yet another process as hop. In contrast,
>>>> peer-to-peer sockets used to be as fast as taps in certain setup (now
>>>> taps became faster again).
>>>>
>>>>        
>>> Dump is critical to maintain.
>>>
>>> sockets is not terribly useful without vlan.  Honestly, I have a hard
>>> time agreeing that it's terribly useful to begin with.  I don't buy an
>>> argument about "ease-of-use" because how to properly configure the
>>> sockets backend is not at all obvious.
>>>      
>> Old style:
>>   -net socket,listen=:12345
>> plus
>>   -net socket,connect=127.0.0.1:12345
>> and you have linked two VMs. New style would be less handy (unless we
>> map -net on -netdev once vlans are gone), but still following the same
>> pattern.
>>    
> 
> For peer-to-peer.  But -net socket + vlan also supports multiple point.

mcast=...?

> 
> And in this example, you're forwarding TCP over TCP which is pretty
> awful from a perf perspective.  Last time I did a quick sniff test with
> -net socket, it was amazingly slow (like 10s of KB/s).

Well, it's not amazing, but even with slow NIC models I usually get
around 150 KB/s. mcast can give you several MB/s on the same host.

> 
>> I bet there is only a minor bit missing to get "-netdev socket" working,
>> given that slirp apparently works. If I had time, I would look into this.
>>    
> 
> I'm sure you could, but the result is a tremendously crippled version of
> -net socket which leads me to wonder if it's still even worth supporting.

I never used >2 peers networks via TCP, so I would not miss them. That's
most efficient with mcast anyway. TCP is fine for ad-hoc peer-to-peer
with zero additional configuration.

Jan

PS: Someone broke TCP socket support in latest qemu, only 0.12.x is fine.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]