From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752215AbbJLMKZ (ORCPT ); Mon, 12 Oct 2015 08:10:25 -0400 Received: from dehamd003.servertools24.de ([31.47.254.18]:60304 "EHLO dehamd003.servertools24.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751444AbbJLMKU (ORCPT ); Mon, 12 Oct 2015 08:10:20 -0400 Subject: Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done To: Felipe Tonello References: <1443528119-31830-1-git-send-email-eu@felipetonello.com> <56178799.9000409@ladisch.de> <561B8882.7060203@ladisch.de> Cc: USB list , Kernel development list , Peter Chen , Greg Kroah-Hartman , Felipe Balbi , Andrzej Pietrasiewicz From: Clemens Ladisch Message-ID: <561BA326.7060209@ladisch.de> Date: Mon, 12 Oct 2015 14:10:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <20151012121017.891650.58535@dehamd003.servertools24.de> X-PPP-Vhost: ladisch.de Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Felipe Tonello wrote: > On Mon, Oct 12, 2015 at 11:16 AM, Clemens Ladisch wrote: >> Felipe Tonello wrote: >>> I believe that is the best way to implement. Create multiple requests >>> until the ALSA substreams buffer are empty and free the request on >>> completion. >> >> I believe a better way to implement this is to allocate a fixed number >> of requests, and to always reuse them. > > How many? Enough to get proper pipelining. At least two, maybe not more. (Depends on how fast those tiny CPUs can queue the next request.) >>> The problem of having requests when host isn't listening will happen >>> anyway because there is no way to know that until completion. >> >> But if you have no upper limit on the number of queues requests, you >> will eventually run out of (DMA) memory. > > And that's what happening at the moment. One of my patches are to fix > a memory leak when that happens. > > But it would be ideal to have a FIFO of requests and perhaps ignore > new requests if the FIFO is full. > > So, allocate (pre-allocate?) new requests until the FIFO is full. Upon > completion, remove the request from FIFO, but still reuse it on > f_midi_transmit() and queue it on the FIFO again if there is still > data from ALSA, otherwise just free the request. Yes, that's exactly what I'm proposing. Regards, Clemens