From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37741 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYeuf-00059n-UY for qemu-devel@nongnu.org; Tue, 13 Jul 2010 08:48:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYeue-0001Nq-J1 for qemu-devel@nongnu.org; Tue, 13 Jul 2010 08:48:41 -0400 Received: from thoth.sbs.de ([192.35.17.2]:22184) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYeue-0001NP-8d for qemu-devel@nongnu.org; Tue, 13 Jul 2010 08:48:40 -0400 Message-ID: <4C3C60A8.7070309@siemens.com> Date: Tue, 13 Jul 2010 14:48:40 +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: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Miguel Di Ciurcio Filho Cc: Markus Armbruster , Luiz Capitulino , qemu-devel@nongnu.org, avi@redhat.com Miguel Di Ciurcio Filho wrote: > 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 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). > 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. What is required for this conversion? And are VDE and Slirp already fully converted? > >> 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. That's still the default network configuration unless you configure something specific (management tools do, of course). > > How about add dump hooks on backends? I don't think network backends > need to be stackable like block devices, thought. That's what I suggested. Definitely an option to migrate the dump feature. > >> 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. As I said: Removing the vlan abstraction is one thing, removing backends is another. I would suggest to start with preparatory work (enable all backends for netdev, port dump, make netdev default), then remove the vlan infrastructure. Jan > > Regards, > > Miguel > > [1] http://wiki.virtualsquare.org/index.php/VDE#vde_plug -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux