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: Wed, 14 Jul 2010 09:28:50 +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

Markus Armbruster wrote:
> Miguel Di Ciurcio Filho <address@hidden> writes:
> 
>> 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].
>> Another option would be to make the socket backend properly work as a
>> netdev, so one could directly connect guest NICs on different hosts,
>> but on a 1:1 relationship.
>>
>>> The dump client helps to debug user mode guest networks, namely slirp
>>> which you did not remove. If that should become the only use case for
>>> vlans with more than 2 nodes, we could think about making it a special
>>> feature of backend devices.
>>>
>> socket and dump are only used when the vlan backends are concerned, so
>> they don't have any useful meaning outside of that.
>>
>> How about add dump hooks on backends? I don't think network backends
>> need to be stackable like block devices, thought.
> 
> Yes, add a dump hook in net.c for netdev in all the places where a dump
> backend on a VLAN gets invoked.

So far dump backends can be hot-added and removed. Once we make them a
property of a netdev backend, monitor support to restore this would be
good. Something like netdev_dump file=FILE[,len=n], empty filename to
disable.

> 
>>> I'm open for cleanups here, but they do require a bit mercy - and should
>>> also mention the reason.
>>>
>> Well, basically there is a lot of "if (vlan) else if (peer)". While
>> discussing the query-netdev QMP command, no one has shown any love
>> about the vlan stuff at all, quite the contrary and it was kept out of
>> the protocol.
> 
> Others are more knowledgable about that than I am, but here's my
> understanding.  VLANs can't be accelerated.  1:1 connection (netdev) is
> almost always just fine.  If you need a virtual LAN, there are better
> tools to build it than QEMU.

That's my understanding as well. But the patch series should state this
to make the decision traceable.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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