[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 04/10] xen/blkfront: separate ring information to an new struct
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 <avanzini.arianna@xxxxxxxxx> > Signed-off-by: Bob Liu <bob.liu@xxxxxxxxxx> > --- > 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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |