From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753891AbbBRRdH (ORCPT ); Wed, 18 Feb 2015 12:33:07 -0500 Received: from smtp02.citrix.com ([66.165.176.63]:43108 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752054AbbBRRdG (ORCPT ); Wed, 18 Feb 2015 12:33:06 -0500 X-IronPort-AV: E=Sophos;i="5.09,603,1418083200"; d="scan'208";a="228249628" Message-ID: <54E4CBD1.1000802@citrix.com> Date: Wed, 18 Feb 2015 18:28:49 +0100 From: =?windows-1252?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Bob Liu , CC: , , , , , , Subject: Re: [PATCH 04/10] xen/blkfront: separate ring information to an new struct References: <1423988345-4005-1-git-send-email-bob.liu@oracle.com> <1423988345-4005-5-git-send-email-bob.liu@oracle.com> In-Reply-To: <1423988345-4005-5-git-send-email-bob.liu@oracle.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-DLP: MIA2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org El 15/02/15 a les 9.18, Bob Liu ha escrit: > A ring is the representation of a hardware queue, this patch separate ring > information from blkfront_info to an new struct blkfront_ring_info to make > preparation for real multi hardware queues supporting. > > Signed-off-by: Arianna Avanzini > Signed-off-by: Bob Liu > --- > drivers/block/xen-blkfront.c | 403 +++++++++++++++++++++++-------------------- > 1 file changed, 218 insertions(+), 185 deletions(-) > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c > index 5a90a51..aaa4a0e 100644 > --- a/drivers/block/xen-blkfront.c > +++ b/drivers/block/xen-blkfront.c > @@ -102,23 +102,15 @@ MODULE_PARM_DESC(max, "Maximum amount of segments in indirect requests (default > #define BLK_RING_SIZE __CONST_RING_SIZE(blkif, PAGE_SIZE) > > /* > - * We have one of these per vbd, whether ide, scsi or 'other'. They > - * hang in private_data off the gendisk structure. We may end up > - * putting all kinds of interesting stuff here :-) > + * Per-ring info. > + * A blkfront_info structure can associate with one or more blkfront_ring_info, > + * depending on how many hardware queues supported. > */ > -struct blkfront_info > -{ > +struct blkfront_ring_info { > spinlock_t io_lock; > - struct mutex mutex; > - struct xenbus_device *xbdev; > - struct gendisk *gd; > - int vdevice; > - blkif_vdev_t handle; > - enum blkif_state connected; > int ring_ref; > struct blkif_front_ring ring; > unsigned int evtchn, irq; > - struct request_queue *rq; > struct work_struct work; > struct gnttab_free_callback callback; > struct blk_shadow shadow[BLK_RING_SIZE]; > @@ -126,6 +118,22 @@ struct blkfront_info > struct list_head indirect_pages; > unsigned int persistent_gnts_c; > unsigned long shadow_free; > + struct blkfront_info *info; AFAICT you seem to have a list of persistent grants, indirect pages and a grant table callback for each ring, isn't this supposed to be shared between all rings? I don't think we should be going down that route, or else we can hoard a large amount of memory and grants.