[Top][All Lists]
[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.
signature.asc
Description: OpenPGP digital signature