From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking Date: Fri, 25 May 2012 14:30:11 +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=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Stefan Hajnoczi , 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: Received: from mx1.redhat.com ([209.132.183.28]:34694 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751242Ab2EYMaU convert rfc822-to-8bit (ORCPT ); Fri, 25 May 2012 08:30:20 -0400 In-Reply-To: (Stefan Hajnoczi's message of "Fri, 25 May 2012 13:01:37 +0100") Sender: kvm-owner@vger.kernel.org List-ID: Stefan Hajnoczi writes: > On Fri, May 25, 2012 at 12:18 PM, Markus Armbruster wrote: >> 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. u= sing 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 >>> =C2=A0 =C2=A0host netdev. =C2=A0Create a hub, attach the guest NIC,= attach the host >>> =C2=A0 =C2=A0netdev, and attach the dump netdev. =C2=A0This allows = the dump netdev to >>> =C2=A0 =C2=A0see all traffic. >>> >>> 2. It lets you build virtual network segments. =C2=A0Several point-= to-point >>> =C2=A0 =C2=A0connections can be brought together. =C2=A0Start 3 VMs= connected by the >>> =C2=A0 =C2=A0"socket" netdev and have one of them use a hub. =C2=A0= This may be >>> =C2=A0 =C2=A0inefficient but I wouldn't be surprised if there are p= eople out there >>> =C2=A0 =C2=A0doing this. >> >> Those people will find other, superior ways to do this once this >> inefficient way is gone. =C2=A0We'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. =C2=A0Today's code makes it harder t= o >>> implement a clean QOM model and is a burden for the net subsystem i= n >>> general. =C2=A0This 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= =2Eh >>> API somehow.) >> >> ... is backward compatiblity really worth the extra net client? >> >> Please excuse my ignorant question (I haven't studied the series): w= hat >> kind of backward compatiblity exactly do we get here? =C2=A0Command = line: >> -net option vlan still works? =C2=A0Or just semantic: whatever you c= ould 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? =C2=A0Why is it worthw= hile to >> provide yet another way within QEMU? > > The aim is to keep the command-line vlan=3D syntax in tact. The hub > change is mostly internal. So it's an extra net client plus somewhat baroque magic to select this client when needed. And when the magic activates, performance suffers. The initiated will expect that, but it'll likely baffle mere users. We can document the issue, but mere users generally don't read documentation. > I agree it would be nice to drop entirely but I don't feel happy doin= g > that to users who might have QEMU buried in scripts somewhere. One > day they upgrade packages and suddenly their stuff doesn't work > anymore. The keywords is "might". Before we bend over backwards, I'd prefer to see some evidence of anyone actually profiting from it. Anyway, maintainer judgement call.