From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37507) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZf8j-0005te-RH for qemu-devel@nongnu.org; Wed, 09 Sep 2015 09:10:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZf8f-00048T-Gg for qemu-devel@nongnu.org; Wed, 09 Sep 2015 09:10:17 -0400 Received: from mx2.suse.de ([195.135.220.15]:49338) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZf8f-00047u-8m for qemu-devel@nongnu.org; Wed, 09 Sep 2015 09:10:13 -0400 References: <1441277113-30693-1-git-send-email-jgross@suse.com> <1441277113-30693-3-git-send-email-jgross@suse.com> <1441373109.19555.7.camel@redhat.com> <55F019F6.30506@suse.com> <1441800060.27149.50.camel@redhat.com> From: Juergen Gross Message-ID: <55F02FB3.6060607@suse.com> Date: Wed, 9 Sep 2015 15:10:11 +0200 MIME-Version: 1.0 In-Reply-To: <1441800060.27149.50.camel@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Patch V1 2/3] xen/usb: add capability for passing through isoc jobs to host devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, stefano.stabellini@eu.citrix.com On 09/09/2015 02:01 PM, Gerd Hoffmann wrote: > Hi, > >>> So, the signaling needs to be different. The host adapter needs to >>> signal somehow that it can handle async iso packets. One way would be >>> to flag this per usb bus, another one per usb packet. Also all xen >>> naming and the xen inlude should go away. BTW: does this build without >>> xen-devel installed? >> >> Okay, I'll try to make it more generic. I think the async iso capability >> should be a bus attribute. > > Makes sense. > >>> Can we get rid of the callbacks? By filling the USBPacket iovec with >>> the iso request chunks for example? >> >> Difficult. One iso request chunk could require multiple iovec entries. > > Why multiple small iovecs instead of one big iovec? The guest buffer might span multiple physical non contiguous pages. I don't want to copy data to a new buffer due to performance reasons (there is already at least one copy operation done by qemu). > usb_host_req_complete_iso_xen() returns a single status for the whole > USBPacket anyway ... I need status per iso request, and libusb does deliver that. >> The RFC version tried to avoid the callbacks and there you didn't like >> exposing the additional structures. > > -ENOPATCH. Aah, sorry, my fault. I think this was part of the off-list discussion we had. Juergen