From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38506) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TvVeB-0004IX-7a for qemu-devel@nongnu.org; Wed, 16 Jan 2013 11:15:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TvVe9-0004BG-9I for qemu-devel@nongnu.org; Wed, 16 Jan 2013 11:15:26 -0500 Received: from e31.co.us.ibm.com ([32.97.110.149]:53707) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TvVe9-0004Ai-2q for qemu-devel@nongnu.org; Wed, 16 Jan 2013 11:15:25 -0500 Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 16 Jan 2013 09:15:23 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 5724A1FF003C for ; Wed, 16 Jan 2013 09:15:05 -0700 (MST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0GGFECM208570 for ; Wed, 16 Jan 2013 09:15:14 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0GGEeb9032041 for ; Wed, 16 Jan 2013 09:14:41 -0700 From: Anthony Liguori In-Reply-To: <20130116151912.GA4023@redhat.com> References: <1356690724-37891-1-git-send-email-jasowang@redhat.com> <8738y3ft2i.fsf@codemonkey.ws> <50F52B97.4000303@redhat.com> <87k3rdjhaa.fsf@codemonkey.ws> <20130116151912.GA4023@redhat.com> Date: Wed, 16 Jan 2013 10:14:33 -0600 Message-ID: <87ip6xcdg6.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 00/12] Multiqueue virtio-net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: krkumar2@in.ibm.com, kvm@vger.kernel.org, mprivozn@redhat.com, Jason Wang , rusty@rustcorp.com.au, qemu-devel@nongnu.org, stefanha@redhat.com, jwhan@filewood.snu.ac.kr, shiyer@redhat.com "Michael S. Tsirkin" writes: > On Wed, Jan 16, 2013 at 09:09:49AM -0600, Anthony Liguori wrote: >> Jason Wang writes: >> >> > On 01/15/2013 03:44 AM, Anthony Liguori wrote: >> >> Jason Wang writes: >> >> >> >>> Hello all: >> >>> >> >>> This seires is an update of last version of multiqueue virtio-net support. >> >>> >> >>> Recently, linux tap gets multiqueue support. This series implements basic >> >>> support for multiqueue tap, nic and vhost. Then use it as an infrastructure to >> >>> enable the multiqueue support for virtio-net. >> >>> >> >>> Both vhost and userspace multiqueue were implemented for virtio-net, but >> >>> userspace could be get much benefits since dataplane like parallized mechanism >> >>> were not implemented. >> >>> >> >>> User could start a multiqueue virtio-net card through adding a "queues" >> >>> parameter to tap. >> >>> >> >>> ./qemu -netdev tap,id=hn0,queues=2,vhost=on -device virtio-net-pci,netdev=hn0 >> >>> >> >>> Management tools such as libvirt can pass multiple pre-created fds through >> >>> >> >>> ./qemu -netdev tap,id=hn0,queues=2,fd=X,fd=Y -device >> >>> virtio-net-pci,netdev=hn0 >> >> I'm confused/frightened that this syntax works. You shouldn't be >> >> allowed to have two values for the same property. Better to have a >> >> syntax like fd[0]=X,fd[1]=Y or something along those lines. >> > >> > Yes, but this what current a StringList type works for command line. >> > Some other parameters such as dnssearch, hostfwd and guestfwd have >> > already worked in this way. Looks like your suggestions need some >> > extension on QemuOps visitor, maybe we can do this on top. >> >> It's a silly syntax and breaks compatibility. This is valid syntax: >> >> -net tap,fd=3,fd=4 >> >> In this case, it means 'fd=4' because the last fd overwrites the first >> one. >> >> Now you've changed it to mean something else. Having one thing mean >> something in one context, but something else in another context is >> terrible interface design. >> >> Regards, >> >> Anthony Liguori > > Aha so just renaming the field 'fds' would address this issue? No, you still have the problem of different meanings. -netdev tap,fd=X,fd=Y -netdev tap,fds=X,fds=Y Would have wildly different behavior. Just do: -netdev tap,fds=X:Y And then we're staying consistent wrt the interpretation of multiple properties of the same name. Regards, Anthony Liguori