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