From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44455 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OLybg-00059Z-9A for qemu-devel@nongnu.org; Tue, 08 Jun 2010 09:12:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OLybQ-0001wB-Dv for qemu-devel@nongnu.org; Tue, 08 Jun 2010 09:12:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64890) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OLybQ-0001vy-3e for qemu-devel@nongnu.org; Tue, 08 Jun 2010 09:12:24 -0400 Date: Tue, 8 Jun 2010 16:07:39 +0300 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans Message-ID: <20100608130739.GD21380@redhat.com> References: <20100607161730.GB11177@redhat.com> <201006071742.56312.paul@codesourcery.com> <4C0D23B5.3050605@codemonkey.ws> <20100607192059.GA14490@redhat.com> <4C0D5959.5010303@codemonkey.ws> <20100607205823.GA14764@redhat.com> <4C0D66A2.4050107@codemonkey.ws> <4C0D6B35.8080000@codemonkey.ws> <20100608121351.GA21380@redhat.com> <4C0E3FA5.9060905@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C0E3FA5.9060905@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Paul Brook , qemu-devel@nongnu.org On Tue, Jun 08, 2010 at 08:03:33AM -0500, Anthony Liguori wrote: > On 06/08/2010 07:13 AM, Michael S. Tsirkin wrote: >> On Mon, Jun 07, 2010 at 04:57:09PM -0500, Anthony Liguori wrote: >> >>> On 06/07/2010 04:37 PM, Anthony Liguori wrote: >>> >>>> On 06/07/2010 03:58 PM, Michael S. Tsirkin wrote: >>>> >>>>> On Mon, Jun 07, 2010 at 03:40:57PM -0500, Anthony Liguori wrote: >>>>> >>>>>> On 06/07/2010 02:21 PM, Michael S. Tsirkin wrote: >>>>>> >>>>>>> So I see two ways to go forward: switch default value in my patch, >>>>>>> or disable vlans unconditionally. >>>>>>> >>>>>>> >>>>>> The problem with disabling vlans unconditionally is that you break -net >>>>>> socket and -net dump. >>>>>> >>>>>> If we can come up with an alternative way to do these things, I'm all >>>>>> for removing it. >>>>>> >>>>> Hmm, I'll try to look at supporting -net socket in netdev. >>>>> Does -net dump do anything that can't be done with tap+tcpdump? >>>>> >>>> tap+tcpdump requires root privileges (even if you have a tap helper). >>>> >>>> Plus tcpdump doesn't help with slirp and -net dump is very useful for >>>> debugging slirp. >>>> >> Developer's need for root access for debugging seems a reasonable price to >> pay to prevent user confusion and complexity that we have now. >> > > Removing vlans has the potential to break existing deployments. That's > something we need to do very cautiously. You mean you want to support both peer to peer and broadcast indefinitely? > What do we gain from removing vlan support today? > > Regards, > > Anthony Liguori This would address the following issues: - people configure vlans and get bad performance - people run --help and see info on vlans instead of peer - migration issues betwen vlan/non-vlan - hotplug is broken for vlan nics >>> Of course, you could add this functionality to netdev. It's arguably >>> better there too because then you can debug virtio-net+tap with full >>> offload enabled (which you cannot do today). >>> >>> Regards, >>> >>> Anthony Liguori >>> >> Care taking on it? I never even heard about -net dump before today. >> >>