From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44641) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXZYB-00048M-Us for qemu-devel@nongnu.org; Thu, 24 May 2012 11:02:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXZY5-0004AI-Gd for qemu-devel@nongnu.org; Thu, 24 May 2012 11:02:03 -0400 Received: from thoth.sbs.de ([192.35.17.2]:32112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXZY5-00048r-7a for qemu-devel@nongnu.org; Thu, 24 May 2012 11:01:57 -0400 Message-ID: <4FBE4D58.8030701@siemens.com> Date: Thu, 24 May 2012 12:01:44 -0300 From: Jan Kiszka MIME-Version: 1.0 References: <1337786045-2277-1-git-send-email-zwu.kernel@gmail.com> <1337786045-2277-14-git-send-email-zwu.kernel@gmail.com> <4FBD0525.4040107@siemens.com> <4FBE2512.50704@siemens.com> <4FBE38AB.8010809@siemens.com> <4FBE44E5.8080206@siemens.com> <4FBE465C.8050502@siemens.com> <4FBE48F4.7080608@siemens.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zhi Yong Wu Cc: "stefanha@linux.vnet.ibm.com" , "kvm@vger.kernel.org" , "linuxram@us.ibm.com" , "qemu-devel@nongnu.org" , "wuzhy@linux.vnet.ibm.com" , "pbonzini@redhat.com" On 2012-05-24 11:51, Zhi Yong Wu wrote: > On Thu, May 24, 2012 at 10:43 PM, Jan Kiszka wrote: >> On 2012-05-24 11:38, Zhi Yong Wu wrote: >>> On Thu, May 24, 2012 at 10:31 PM, Jan Kiszka wrote: >>>> On 2012-05-24 11:27, Zhi Yong Wu wrote: >>>>> On Thu, May 24, 2012 at 10:25 PM, Jan Kiszka wrote: >>>>>> Something mangled your reply and made it unreadable. Please retry. >>>>> Sorry. let it look like below. Do you think of it? typ=hubport >>>>> >>>>> (qemu) info network >>>>> virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 >>>>> \ hub0port0: type=hubport, >>>>> virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 >>>>> \ hub1port0: type=hubport, >>>>> virtio-net-pci.2: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:58 >>>>> \ u: type=user,net=10.0.2.0,restrict=off >>>>> e1000.0: type=nic,model=e1000,macaddr=52:54:00:12:34:59 >>>>> \ ur: type=user,net=10.0.2.0,restrict=off >>>>> hub 1 >>>>> port 1 peer user.1 >>>>> port 0 peer virtio-net-pci.1 >>>>> hub 0 >>>>> port 1 peer user.0 >>>>> port 0 peer virtio-net-pci.0 >>>> >>>> My question remains: What added value we get from listing the hubs with >>>> its ports separately from the port connections? Also, how would this be >>>> printed: >>>> >>>> -net user -net dump -net nic >>> (qemu) info network >>> virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 >>> \ hub0port0: type=hubport, >>> virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 >>> \ hub1port0: type=hubport, >>> hub 1 >>> port 2 peer dump.0 >>> port 1 peer user.1 >>> port 0 peer virtio-net-pci.1 >>> hub 0 >>> port 1 peer user.0 >>> port 0 peer virtio-net-pci.0 >>> (qemu) >>> >>>> >>>> The user should only be interested in the fact that user.0, dump.0 and >>>> .0 are attached to the same hub, not to which port of that hub. >>> OK, then let it seem like below. right? >>> >>> (qemu) info network >>> virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 >>> \ hub0port0: type=hubport, >>> virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 >>> \ hub1port0: type=hubport, >>> hub 1 >>> \ dump.0 >>> \ user.1 >>> \ virtio-net-pci.1 >>> hub 0 >>> \ user.0 >>> \ virtio-net-pci.0 >>> (qemu) >> >> And, still, what is the added value of this verbose form compared to my > They are same, i think. Then let's got for the more compact form I proposed. >> compact proposal? Please don't remark that it's easier to implement. ;) > The implementation is not one difficult thing, if we reach agreement > about its layout. > For those NIC which aren't in one hub, they should been kept compact > with old qemu form. Yes. The form would be peer \ peer for the classic couples and hub \ peer \ peer \ ... for those that are attached to a hub. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux