From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: [PATCH v3 00/16] net: hub-based networking Date: Fri, 25 May 2012 13:18:35 +0200 Message-ID: References: <1337882362-20100-1-git-send-email-zwu.kernel@gmail.com> <20120524175321.31254444@doriath.home> <20120525100753.GD30110@stefanha-thinkpad.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, jan.kiszka@siemens.com, qemu-devel@nongnu.org, Luiz Capitulino , zwu.kernel@gmail.com, wuzhy@linux.vnet.ibm.com, pbonzini@redhat.com To: Stefan Hajnoczi Return-path: In-Reply-To: <20120525100753.GD30110@stefanha-thinkpad.localdomain> (Stefan Hajnoczi's message of "Fri, 25 May 2012 11:07:53 +0100") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org Stefan Hajnoczi writes: > On Thu, May 24, 2012 at 05:53:21PM -0300, Luiz Capitulino wrote: >> On Fri, 25 May 2012 01:59:06 +0800 >> zwu.kernel@gmail.com wrote: >> >> > From: Zhi Yong Wu >> > >> > The patchset implements network hub stead of vlan. The main work was done by stefan, and i rebased it to latest QEMU upstream, did some testings and am responsible for pushing it to QEMU upstream. >> >> Honest question: does it really pay off to have this in qemu vs. using one of >> the externaly available solutions? > > For typical KVM setups this feature will be unused. > > However, the legacy QEMU "vlan" feature does have a few uses: > > 1. It's how the "dump" netdev can be connected up with a guest NIC and > host netdev. Create a hub, attach the guest NIC, attach the host > netdev, and attach the dump netdev. This allows the dump netdev to > see all traffic. > > 2. It lets you build virtual network segments. Several point-to-point > connections can be brought together. Start 3 VMs connected by the > "socket" netdev and have one of them use a hub. This may be > inefficient but I wouldn't be surprised if there are people out there > doing this. Those people will find other, superior ways to do this once this inefficient way is gone. We'd do them a favour, I'd say ;) > The point of this patch series is to remove the special-case net.c code > for the legacy "vlan" feature. Today's code makes it harder to > implement a clean QOM model and is a burden for the net subsystem in > general. This series takes the vlan functionality and puts it into a > normal netdev - it extracts the feature from net.c. Welcome improvement, but... > (If we didn't care about backwards compatibility we could just drop > vlans completely and rewrite the "dump" netdev to hook into the net.h > API somehow.) ... is backward compatiblity really worth the extra net client? Please excuse my ignorant question (I haven't studied the series): what kind of backward compatiblity exactly do we get here? Command line: -net option vlan still works? Or just semantic: whatever you could do with vlans you can now do with hubs? In case it's the latter: well, whatever you could do with vlans you can already do with external software, can't you? Why is it worthwhile to provide yet another way within QEMU? From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58305) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXsXe-00038k-EP for qemu-devel@nongnu.org; Fri, 25 May 2012 07:18:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXsXZ-0006TG-FL for qemu-devel@nongnu.org; Fri, 25 May 2012 07:18:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64382) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXsXZ-0006T6-73 for qemu-devel@nongnu.org; Fri, 25 May 2012 07:18:41 -0400 From: Markus Armbruster References: <1337882362-20100-1-git-send-email-zwu.kernel@gmail.com> <20120524175321.31254444@doriath.home> <20120525100753.GD30110@stefanha-thinkpad.localdomain> Date: Fri, 25 May 2012 13:18:35 +0200 In-Reply-To: <20120525100753.GD30110@stefanha-thinkpad.localdomain> (Stefan Hajnoczi's message of "Fri, 25 May 2012 11:07:53 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kvm@vger.kernel.org, jan.kiszka@siemens.com, qemu-devel@nongnu.org, Luiz Capitulino , zwu.kernel@gmail.com, wuzhy@linux.vnet.ibm.com, pbonzini@redhat.com Stefan Hajnoczi writes: > On Thu, May 24, 2012 at 05:53:21PM -0300, Luiz Capitulino wrote: >> On Fri, 25 May 2012 01:59:06 +0800 >> zwu.kernel@gmail.com wrote: >> >> > From: Zhi Yong Wu >> > >> > The patchset implements network hub stead of vlan. The main work was done by stefan, and i rebased it to latest QEMU upstream, did some testings and am responsible for pushing it to QEMU upstream. >> >> Honest question: does it really pay off to have this in qemu vs. using one of >> the externaly available solutions? > > For typical KVM setups this feature will be unused. > > However, the legacy QEMU "vlan" feature does have a few uses: > > 1. It's how the "dump" netdev can be connected up with a guest NIC and > host netdev. Create a hub, attach the guest NIC, attach the host > netdev, and attach the dump netdev. This allows the dump netdev to > see all traffic. > > 2. It lets you build virtual network segments. Several point-to-point > connections can be brought together. Start 3 VMs connected by the > "socket" netdev and have one of them use a hub. This may be > inefficient but I wouldn't be surprised if there are people out there > doing this. Those people will find other, superior ways to do this once this inefficient way is gone. We'd do them a favour, I'd say ;) > The point of this patch series is to remove the special-case net.c code > for the legacy "vlan" feature. Today's code makes it harder to > implement a clean QOM model and is a burden for the net subsystem in > general. This series takes the vlan functionality and puts it into a > normal netdev - it extracts the feature from net.c. Welcome improvement, but... > (If we didn't care about backwards compatibility we could just drop > vlans completely and rewrite the "dump" netdev to hook into the net.h > API somehow.) ... is backward compatiblity really worth the extra net client? Please excuse my ignorant question (I haven't studied the series): what kind of backward compatiblity exactly do we get here? Command line: -net option vlan still works? Or just semantic: whatever you could do with vlans you can now do with hubs? In case it's the latter: well, whatever you could do with vlans you can already do with external software, can't you? Why is it worthwhile to provide yet another way within QEMU?