From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MwHMM-0003VH-SJ for qemu-devel@nongnu.org; Fri, 09 Oct 2009 11:26:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MwHMH-0003HR-Dz for qemu-devel@nongnu.org; Fri, 09 Oct 2009 11:26:21 -0400 Received: from [199.232.76.173] (port=57365 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MwHMH-0003H9-4I for qemu-devel@nongnu.org; Fri, 09 Oct 2009 11:26:17 -0400 Received: from fg-out-1718.google.com ([72.14.220.159]:42518) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MwHMG-00075N-Pm for qemu-devel@nongnu.org; Fri, 09 Oct 2009 11:26:16 -0400 Received: by fg-out-1718.google.com with SMTP id e21so294492fga.10 for ; Fri, 09 Oct 2009 08:26:15 -0700 (PDT) Message-ID: <4ACF5612.7030400@codemonkey.ws> Date: Fri, 09 Oct 2009 10:26:10 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 00/16] Add a -netdev option References: <1255028312-28180-1-git-send-email-markmc@redhat.com> In-Reply-To: <1255028312-28180-1-git-send-email-markmc@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: Mark McLoughlin Cc: Avi Kivity , qemu-devel@nongnu.org, "Michael S. Tsirkin" Hi Mark, Mark McLoughlin wrote: > Hi, > Here's a series of patches which gets the ball rolling on adding > a -netdev option. > > The idea is to de-emphasise the vlan support, and instead make > a nic directly connected to a host backend the default and recommended > configuration. We want this because it is only with this configuration > that we feasibly add optimizations like GSO support or vhost-net. > I think this series is a good first step. I've looked through the patches and they all look pretty good. I plan on pushing after some testing assuming noone objects in the interim. With respect to moving forward, I wanted to bring up a couple of topics. To eliminate VLANs, I think the reasonable approach is to implemented an emulated hub. I'd suggest treating the hub like a device. Instantiate it through qdev, support it via -device, etc. I think it would even be reasonable to have it support a fixed number of ports. I doubt there would be any compatibility issues emulating a 32-bit port hub, for instance. The current syntax would become just a convenient short cut for the -netdev syntax along with creating a hub device for each vlan that gets instantiated. I think merging vhost_net support will depend on finishing out the netdev work. Logically, I think vhost_net is a netdev backend and we extend the netdev API to support async submission of packets (basically mirroring the virtio-net ABI). In the case of a virtio-net front-end to a vhost_net backend, I think we special case that assuming we're running kvm. Regards, Anthony Liguori