From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42893) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKtlX-0008TT-C9 for qemu-devel@nongnu.org; Mon, 31 Oct 2011 11:27:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RKtga-00089L-Bq for qemu-devel@nongnu.org; Mon, 31 Oct 2011 11:22:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38200) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKtgY-00088g-Dz for qemu-devel@nongnu.org; Mon, 31 Oct 2011 11:22:03 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p9VFM0sn014963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 31 Oct 2011 11:22:00 -0400 Received: from shalem.localdomain (vpn1-4-232.ams2.redhat.com [10.36.4.232]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p9VFLwcO029979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 31 Oct 2011 11:22:00 -0400 Message-ID: <4EAEBD2D.6070704@redhat.com> Date: Mon, 31 Oct 2011 16:22:21 +0100 From: Hans de Goede MIME-Version: 1.0 References: <4EAE6A16.60303@obes.name> <4EAE98A4.6000700@redhat.com> <4EAEA4A0.0@obes.name> In-Reply-To: <4EAEA4A0.0@obes.name> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Performance of USB2.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi, On 10/31/2011 02:37 PM, Til Obes wrote: > Hi. > > Am 31.10.2011 13:46, schrieb Hans de Goede: >> If you're using libvirt to start qemu, then it will also pass >> -usb to qemu, so you will have both a usb-1 (uhci) and a usb-2 >> (ehci) controller inside your vm, since your hostdev xml code does >> not specify a bus the hostdev will likely get connected to the first >> usb bus which is the one attached to the uhci controller, although >> your lsusb output suggests otherwise (to my surprise). > > > > So assuming that I'm reading your lsusb output correct, the device > > does seem to be connected to the virtual ehci controller rather then > > to the virtual uhci controller, which more or less rules that out > > as the cause. > > > The kernel output says: > router:~# dmesg|grep usb > [ 0.418314] usbcore: registered new interface driver usbfs > [ 0.418401] usbcore: registered new interface driver hub > [ 0.419256] usbcore: registered new device driver usb > [ 0.488137] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 > [ 0.488144] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > [ 0.488150] usb usb1: Product: EHCI Host Controller > [ 0.488155] usb usb1: Manufacturer: Linux 2.6.32-5-amd64 ehci_hcd > [ 0.488160] usb usb1: SerialNumber: 0000:00:07.0 > [ 0.488437] usb usb1: configuration #1 chosen from 1 choice > [ 1.155604] usb 1-1: new high speed USB device using ehci_hcd and address 2 > [ 1.665760] usb 1-1: New USB device found, idVendor=9710, idProduct=7830 > [ 1.665781] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > [ 1.665784] usb 1-1: Product: USB-MAC Controller > [ 1.665786] usb 1-1: Manufacturer: Moschip Semiconductor > [ 1.665787] usb 1-1: SerialNumber: 3b0c00d1 > [ 1.665886] usb 1-1: configuration #1 chosen from 1 choice > [ 1.877906] usb 1-1: applying rev.C fixup > [ 1.890249] usb 1-1: applying rev.C fixup > [ 1.905011] eth2: register 'MOSCHIP usb-ethernet driver' at usb-0000:00:07.0-1, MOSCHIP 7830/7730 usb-NET adapter, 00:13:3b:0c:00:d1 > [ 1.905028] usbcore: registered new interface driver MOSCHIP usb-ethernet driver > > So it should work with my configuration... > Agreed. >> This means that the likely cause is just that usb emulation / pass >> through causes quite a bit of overhead, which is not unexpected since >> both the usb protocol and the ehci controller interface are both quite >> hard to emulate. > > But 6Mbit from 480MBit is quite low, at least 100MBit should be realistic or? That depends on how the protocol between the NIC and the usb host works, it likely is using bulk transfers, and likely only 1 at a time, which means that latency becomes an important issue, and usb redirection of bulk transfers causes quite a bit of latency. > >> It is likely better to just use the usb nic directly from the host, >> and then pass it through the virtio-net using bridging. > > Well the cable modem is only talking to the first mac address it gets. > In my setup eth1 is the bridged nic to the cable box and it isnt > working. Any suggestions how to solve this? If the cable box wants to use the usb-nic, then why not let the host drive the usb-host and bridge the usb-nic rather then eth1 to the virtual machine? Regards, Hans