qemu-devel
[Top][All Lists]
Advanced

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

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


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH 0/8] vlan cleanup
Date: Tue, 13 Jul 2010 22:12:42 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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<address@hidden>  
>>>>> 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: signature.asc
Description: OpenPGP digital signature


reply via email to

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