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: Anthony Liguori
Subject: [Qemu-devel] Re: [PATCH 0/8] vlan cleanup
Date: Tue, 13 Jul 2010 14:22:47 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100528 Lightning/1.0b1 Thunderbird/3.0.5

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.

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).

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.

Regards,

Anthony Liguori

Jan





reply via email to

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