From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58905) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ux138-0005jr-4W for qemu-devel@nongnu.org; Wed, 10 Jul 2013 16:31:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ux135-0002SE-Tp for qemu-devel@nongnu.org; Wed, 10 Jul 2013 16:31:42 -0400 Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:51633 helo=mx01.kamp.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Ux135-0002S3-JL for qemu-devel@nongnu.org; Wed, 10 Jul 2013 16:31:39 -0400 Message-ID: <51DDC4A6.4060000@kamp.de> Date: Wed, 10 Jul 2013 22:31:34 +0200 From: Peter Lieven MIME-Version: 1.0 References: <1372338695-411-1-git-send-email-pl@kamp.de> <1372338695-411-11-git-send-email-pl@kamp.de> <20130710113313.GK3898@dhcp-200-207.str.redhat.com> <51DD69F8.3050305@kamp.de> <20130710142807.GQ3898@dhcp-200-207.str.redhat.com> <51DD7472.9020303@kamp.de> <20130710145816.GX3898@dhcp-200-207.str.redhat.com> In-Reply-To: <20130710145816.GX3898@dhcp-200-207.str.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCHv2 10/11] iscsi: ignore aio_discard if unsupported List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: pbonzini@redhat.com, ronniesahlberg@gmail.com, qemu-devel@nongnu.org, stefanha@redhat.com Am 10.07.2013 16:58, schrieb Kevin Wolf: > Am 10.07.2013 um 16:49 hat Peter Lieven geschrieben: >> Am 10.07.2013 16:28, schrieb Kevin Wolf: >>> Am 10.07.2013 um 16:04 hat Peter Lieven geschrieben: >>>> Am 10.07.2013 13:33, schrieb Kevin Wolf: >>>>> Am 27.06.2013 um 15:11 hat Peter Lieven geschrieben: >>>>>> if the target does not support UNMAP or the request >>>>>> is too big silently ignore the discard request. >>>>>> >>>>>> Signed-off-by: Peter Lieven >>>>> Why not loop for the "too big" case? You can probably use the same logic >>>>> for unmapping the whole device in .bdrv_create and here. >>>> right, but looping in an aio function seemed not so trivial to me. >>>> it seems more and more obvious to me that the best would be to change >>>> all the remaining aio routines to co routines. >>> The pattern for AIO functions is that the real work of submitting >>> requests is done in the AIO callback, and it submits new AIO requests >>> calling back into the same callback as long as acb->remaining_secs > 0 >>> (or something like that). >>> >>> You can still see that kind of thing alive in qed_aio_next_io(), (most >>> of?) the rest is converted to coroutines because it makes the code look >>> nicer. >> would you agree if I leave the easy version in just to fix the potential >> problems if iscsi_aio_discard is called with too high nb_sectors or >> on a storage where UNMAP is unsupported. >> >> I will add a TODO with the comment that the limit of iscsi->max_unmap should >> be replaced by a loop once the routine is replaced by a coroutine? > Meh, another pony I don't get... ;-) > > Leaving a TODO comment for now is okay with me. forget about the TODO. Looking at what I have already got, implementing iscsi_co_discard is low hanging fruit. I will implement it directly. With the too big loop and all the benefits of the co routines. Peter