From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54030) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOjA7-0000q4-VE for qemu-devel@nongnu.org; Thu, 18 Oct 2012 02:00:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TOjA6-0002A7-Jg for qemu-devel@nongnu.org; Thu, 18 Oct 2012 02:00:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10266) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOjA6-000286-B5 for qemu-devel@nongnu.org; Thu, 18 Oct 2012 02:00:54 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9I60obn001086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 18 Oct 2012 02:00:52 -0400 Message-ID: <507F9B0B.4080606@redhat.com> Date: Thu, 18 Oct 2012 08:00:43 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1350297511-25437-1-git-send-email-hdegoede@redhat.com> <1350297511-25437-15-git-send-email-hdegoede@redhat.com> <507E96A3.6020101@redhat.com> <507EC3A3.6080201@redhat.com> In-Reply-To: <507EC3A3.6080201@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 14/22] usb: Add packet combining functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hans de Goede Cc: qemu-devel@nongnu.org Hi, > For handle_combined_data, yes, as usb_ep_combine_input_packets can > cause multiple packets to get submitted, since if a combined packet > ends with a packet, which does not have its short_not_ok flag set, > another packet can be safely pipelined after it. This is not > useful for usb mass storage, but very usefull for usb serial > port converters. Ah, I see. You can have a queue with -- say -- 16 packets which will get combined into 4 groups with 4 packets each -> 4 callbacks. I think handle_combined_data() should get USBCombinedPacket passed instead of USBPacket. It is cleaner API-wise. Likewise for the other usb_combined_* functions. Allowing to call usb_ep_combine_input_packets on any endpoint (except iso which is a special case anyway) would be good too I think, then it is possible for usb drivers to operate on USBCombinedPackets everywhere. BTW: I think USBPacketGroup would be a better name for USBCombinedPacket. cheers, Gerd