From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35234) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFtyv-0000ve-13 for qemu-devel@nongnu.org; Fri, 29 Apr 2011 16:08:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QFtyu-0000Sv-8I for qemu-devel@nongnu.org; Fri, 29 Apr 2011 16:08:04 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:63085) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QFtyu-0000Sp-5z for qemu-devel@nongnu.org; Fri, 29 Apr 2011 16:08:04 -0400 Received: by gxk26 with SMTP id 26so1780201gxk.4 for ; Fri, 29 Apr 2011 13:08:03 -0700 (PDT) Message-ID: <4DBB1A9F.2050803@codemonkey.ws> Date: Fri, 29 Apr 2011 15:07:59 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20110420082706.32157.59668.stgit@dhcp-91-7.nay.redhat.com.englab.nay.redhat.com> <20110420083318.32157.63955.stgit@dhcp-91-7.nay.redhat.com.englab.nay.redhat.com> In-Reply-To: <20110420083318.32157.63955.stgit@dhcp-91-7.nay.redhat.com.englab.nay.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 1/2] net: Add multiqueue support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Wang Cc: krkumar2@in.ibm.com, kvm@vger.kernel.org, mst@redhat.com, netdev@vger.kernel.org, rusty@rustcorp.com.au, qemu-devel@nongnu.org On 04/20/2011 03:33 AM, Jason Wang wrote: > This patch adds the multiqueues support for emulated nics. Each VLANClientState > pairs are now abstract as a queue instead of a nic, and multiple VLANClientState > pointers were stored in the NICState and treated as the multiple queues of a > single nic. The netdev options of qdev were now expanded to accept more than one > netdev ids. A queue_index were also introduced to let the emulated nics know > which queue the packet were came from or sent out. Virtio-net would be the first > user. > > The legacy single queue nics can still run happily without modification as the > the compatibility were kept. > > Signed-off-by: Jason Wang > --- > hw/qdev-properties.c | 37 ++++++++++++++++++++++++++++++------- > hw/qdev.h | 3 ++- > net.c | 34 ++++++++++++++++++++++++++-------- > net.h | 15 +++++++++++---- > 4 files changed, 69 insertions(+), 20 deletions(-) > > diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c > index 1088a26..dd371e1 100644 > --- a/hw/qdev-properties.c > +++ b/hw/qdev-properties.c > @@ -384,14 +384,37 @@ PropertyInfo qdev_prop_chr = { > > static int parse_netdev(DeviceState *dev, Property *prop, const char *str) > { > - VLANClientState **ptr = qdev_get_prop_ptr(dev, prop); > + VLANClientState ***nc = qdev_get_prop_ptr(dev, prop); > + const char *ptr = str; > + int i = 0; > + size_t len = strlen(str); > + *nc = qemu_malloc(MAX_QUEUE_NUM * sizeof(VLANClientState *)); > + > + while (i< MAX_QUEUE_NUM&& ptr< str + len) { > + char *name = NULL; > + char *this = strchr(ptr, '#'); However this is being used is not going to be right. Is this taking netdev=a#b#c#d? I sort of agree with Michael about using multiple netdevs for this but I don't yet understand how this gets sets up from userspace. Can you give an example of usage that involves the full tap device setup? Ideally, a user/management tool would never need to know about any of this. In a perfect world, we could just dup() the tap fd a few times to create multiple queues. Regards, Anthony Liguori