From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Hitting 29 NIC limit Date: Thu, 14 Oct 2010 09:11:10 -0500 Message-ID: <4CB70F7E.30308@codemonkey.ws> References: <4CB6388A.30006@codemonkey.ws> <4CB6F275.2060204@redhat.com> <4CB6FD7E.7010606@codemonkey.ws> <4CB7044A.4050705@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Anjali Kulkarni , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" To: Avi Kivity Return-path: Received: from mail-iw0-f174.google.com ([209.85.214.174]:51614 "EHLO mail-iw0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754430Ab0JNOLS (ORCPT ); Thu, 14 Oct 2010 10:11:18 -0400 Received: by iwn35 with SMTP id 35so20815iwn.19 for ; Thu, 14 Oct 2010 07:11:17 -0700 (PDT) In-Reply-To: <4CB7044A.4050705@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 10/14/2010 08:23 AM, Avi Kivity wrote: > On 10/14/2010 02:54 PM, Anthony Liguori wrote: >>>> The key is to make the virtio-net devices multifunction and to fill >>>> out all 8 functions for each slot. >>> >>> This is unlikely to work right wrt pci hotplug. >> >> >> Yes. Our hotplug design is based on devices.. This is wrong, it >> should be based on bus-level concepts (like PCI slots). >> >>> If we want to support a large number of interfaces, we need true >>> multiport cards. >> >> This magic here creates a multiport virtio-net card so I'm not really >> sure what you're suggesting. It would certainly be nice to make this >> all more user friendly (and make hotplug work). >> > > The big issue is to fix hotplug. Yes, but this is entirely independent of multifunction devices. Today we shoe-horn hot remove into device_del. Instead, we should have explicit bus-level interfaces for hot remove. Regards, Anthony Liguori > I don't see how we can make it user friendly, without making the > ordinary case even more unfriendly. Looks like we need yet another > level of indirection here. > From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37587 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P6OWx-0004PL-KB for qemu-devel@nongnu.org; Thu, 14 Oct 2010 10:11:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P6OWe-000843-Kf for qemu-devel@nongnu.org; Thu, 14 Oct 2010 10:11:21 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:49657) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P6OWe-00083x-HB for qemu-devel@nongnu.org; Thu, 14 Oct 2010 10:11:20 -0400 Received: by iwn34 with SMTP id 34so6781687iwn.4 for ; Thu, 14 Oct 2010 07:11:20 -0700 (PDT) Message-ID: <4CB70F7E.30308@codemonkey.ws> Date: Thu, 14 Oct 2010 09:11:10 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Hitting 29 NIC limit References: <4CB6388A.30006@codemonkey.ws> <4CB6F275.2060204@redhat.com> <4CB6FD7E.7010606@codemonkey.ws> <4CB7044A.4050705@redhat.com> In-Reply-To: <4CB7044A.4050705@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Anjali Kulkarni , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" On 10/14/2010 08:23 AM, Avi Kivity wrote: > On 10/14/2010 02:54 PM, Anthony Liguori wrote: >>>> The key is to make the virtio-net devices multifunction and to fill >>>> out all 8 functions for each slot. >>> >>> This is unlikely to work right wrt pci hotplug. >> >> >> Yes. Our hotplug design is based on devices.. This is wrong, it >> should be based on bus-level concepts (like PCI slots). >> >>> If we want to support a large number of interfaces, we need true >>> multiport cards. >> >> This magic here creates a multiport virtio-net card so I'm not really >> sure what you're suggesting. It would certainly be nice to make this >> all more user friendly (and make hotplug work). >> > > The big issue is to fix hotplug. Yes, but this is entirely independent of multifunction devices. Today we shoe-horn hot remove into device_del. Instead, we should have explicit bus-level interfaces for hot remove. Regards, Anthony Liguori > I don't see how we can make it user friendly, without making the > ordinary case even more unfriendly. Looks like we need yet another > level of indirection here. >