From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752307AbbJFJ6L (ORCPT ); Tue, 6 Oct 2015 05:58:11 -0400 Received: from smtp02.citrix.com ([66.165.176.63]:5645 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750936AbbJFJ6K (ORCPT ); Tue, 6 Oct 2015 05:58:10 -0400 X-IronPort-AV: E=Sophos;i="5.17,643,1437436800"; d="scan'208";a="308340876" Subject: Re: [Xen-devel] [PATCH 2/2] block/xen-blkfront: Handle non-indirect grant with 64KB pages To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , References: <1441999920-3639-1-git-send-email-julien.grall@citrix.com> <1441999920-3639-3-git-send-email-julien.grall@citrix.com> <56129EEF.9090702@citrix.com> <5612ADEB.40002@citrix.com> <561396DF.9040406@citrix.com> CC: , , , David Vrabel , "Boris Ostrovsky" From: Julien Grall Message-ID: <56139B2A.1050809@citrix.com> Date: Tue, 6 Oct 2015 10:58:02 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <561396DF.9040406@citrix.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-DLP: MIA2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Roger, On 06/10/2015 10:39, Roger Pau Monné wrote: > El 05/10/15 a les 19.05, Julien Grall ha escrit: >> On 05/10/15 17:01, Roger Pau Monné wrote: >>> El 11/09/15 a les 21.32, Julien Grall ha escrit: >>>> ring_req->u.rw.nr_segments = num_grant; >>>> + if (unlikely(require_extra_req)) { >>>> + id2 = blkif_ring_get_request(info, req, &ring_req2); >>> >>> How can you guarantee that there's always going to be another free >>> request? AFAICT blkif_queue_rq checks for RING_FULL, but you don't >>> actually know if there's only one slot or more than one available. >> >> Because the depth of the queue is divided by 2 when the extra request is >> used (see xlvbd_init_blk_queue). I just noticed that I didn't mention this restriction in the commit message. I will do it in the next revision. > I see, that's quite restrictive but I guess it's better than introducing > a new ring macro in order to figure out if there are at least two free > slots. I actually didn't think about your suggestion. I choose to divide by two based on the assumption that the block framework will always try to send a request with the maximum data possible. I don't know if this assumption is correct as I'm not fully aware how the block framework is working. If it's valid, in the case of 64KB guest, the maximum size of a request would be 64KB when indirect segment is not supported. So we would end up with a lot of 64KB request which will require 2 ring request. Regards, -- Julien Grall