From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37508 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYwPH-0000YA-VM for qemu-devel@nongnu.org; Wed, 14 Jul 2010 03:29:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYwPG-0006bY-Na for qemu-devel@nongnu.org; Wed, 14 Jul 2010 03:29:27 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:36779) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYwPG-0006bJ-AK for qemu-devel@nongnu.org; Wed, 14 Jul 2010 03:29:26 -0400 Message-ID: <4C3D6732.7060306@web.de> Date: Wed, 14 Jul 2010 09:28:50 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1278962453-15774-1-git-send-email-miguel.filho@gmail.com> <4C3C04C4.8050804@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA514C6B4FFF128D8D6110DE6" 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: Markus Armbruster Cc: Luiz Capitulino , Miguel Di Ciurcio Filho , qemu-devel@nongnu.org, avi@redhat.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA514C6B4FFF128D8D6110DE6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Markus Armbruster wrote: > Miguel Di Ciurcio Filho writes: >=20 >> On Tue, Jul 13, 2010 at 3:16 AM, Jan Kiszka 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 tes= ts 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 purpos= es >>> 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 specia= l >>> 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. >=20 > 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=3DFILE[,len=3Dn], empty filename to= disable. >=20 >>> I'm open for cleanups here, but they do require a bit mercy - and sho= uld >>> 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. >=20 > 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 --------------enigA514C6B4FFF128D8D6110DE6 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 iEYEARECAAYFAkw9ZzMACgkQitSsb3rl5xS5rgCcDz6psJFkgyqXPg1mPZlU8DBT B1cAn3yWSqBNAqCnkRj1kTEFBD21Xag0 =P1hr -----END PGP SIGNATURE----- --------------enigA514C6B4FFF128D8D6110DE6--