From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52815 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYlqU-000083-TB for qemu-devel@nongnu.org; Tue, 13 Jul 2010 16:12:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYlqS-00008G-Ep for qemu-devel@nongnu.org; Tue, 13 Jul 2010 16:12:50 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:56077) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYlqS-000082-2Y for qemu-devel@nongnu.org; Tue, 13 Jul 2010 16:12:48 -0400 Message-ID: <4C3CC8BA.4090909@web.de> Date: Tue, 13 Jul 2010 22:12:42 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1278962453-15774-1-git-send-email-miguel.filho@gmail.com> <4C3C04C4.8050804@web.de> <4C3C60A8.7070309@siemens.com> <4C3CB5C1.5010307@codemonkey.ws> <4C3CB9AB.1070607@web.de> <4C3CBD07.4020503@codemonkey.ws> In-Reply-To: <4C3CBD07.4020503@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7E14BECC3BAFDFABF3BA84AC" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH 0/8] vlan cleanup List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, avi@redhat.com, Miguel Di Ciurcio Filho , Markus Armbruster , Luiz Capitulino This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7E14BECC3BAFDFABF3BA84AC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anthony Liguori wrote: > On 07/13/2010 02:08 PM, Jan Kiszka wrote: >> Anthony Liguori wrote: >> =20 >>> On 07/13/2010 07:48 AM, Jan Kiszka wrote: >>> =20 >>>> Miguel Di Ciurcio Filho wrote: >>>> >>>> =20 >>>>> On Tue, Jul 13, 2010 at 3:16 AM, Jan Kiszka =20 >>>>> wrote: >>>>> >>>>> =20 >>>>>> Miguel Di Ciurcio Filho wrote: >>>>>> >>>>>> =20 >>>>>>> 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 >>>>>>> >>>>>>> =20 >>>>>> Sorry, this is a bit too rude. This not only removes the vlan mode= l, >>>>>> something one may talk about, but also the innocent socket back-en= ds >>>>>> and >>>>>> the useful pcap dump support. >>>>>> >>>>>> Socket back-ends allow quick and easy unprivileged inter-VM networ= k >>>>>> setups. Nothing for production systems, but useful for testing >>>>>> purposes >>>>>> on boxes where taps are not allowed or unhandy to configure. >>>>>> >>>>>> >>>>>> =20 >>>>> 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]. >>>>> >>>>> =20 >>>> 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 (no= w >>>> taps became faster again). >>>> >>>> =20 >>> 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 a= n >>> argument about "ease-of-use" because how to properly configure the >>> sockets backend is not at all obvious. >>> =20 >> Old style: >> -net socket,listen=3D:12345 >> plus >> -net socket,connect=3D127.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. >> =20 >=20 > For peer-to-peer. But -net socket + vlan also supports multiple point.= mcast=3D...? >=20 > 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. >=20 >> I bet there is only a minor bit missing to get "-netdev socket" workin= g, >> given that slirp apparently works. If I had time, I would look into th= is. >> =20 >=20 > I'm sure you could, but the result is a tremendously crippled version o= f > -net socket which leads me to wonder if it's still even worth supportin= g. 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.= --------------enig7E14BECC3BAFDFABF3BA84AC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkw8yL8ACgkQitSsb3rl5xRSLgCgldSBPlQCUaNxQTsyTN8z+7ya ArQAn3Eu24OJRC9+YSQUbaPyD/wI0/dC =EVCM -----END PGP SIGNATURE----- --------------enig7E14BECC3BAFDFABF3BA84AC--