Re: [PATCH RFC 1/4] xen, blkfront: add support for the multi-queue block layer API

[David Vrabel]

On 22/08/14 12:20, Arianna Avanzini wrote:
> This commit introduces support for the multi-queue block layer API.
> The changes are only structural, and force both the use of the
> multi-queue API and the use of a single I/O ring, by initializing
> statically the number of hardware queues to one.
[...]
> @@ -98,6 +99,8 @@ static unsigned int xen_blkif_max_segments = 32;
>  module_param_named(max, xen_blkif_max_segments, int, S_IRUGO);
>  MODULE_PARM_DESC(max, "Maximum amount of segments in indirect requests (default is 32)");
>  
> +static unsigned int hardware_queues = 1;
> +
>  #define BLK_RING_SIZE __CONST_RING_SIZE(blkif, PAGE_SIZE)
>  
>  /*
> @@ -134,6 +137,8 @@ struct blkfront_info
>  	unsigned int feature_persistent:1;
>  	unsigned int max_indirect_segments;
>  	int is_ready;
> +	/* Block layer tags. */
> +	struct blk_mq_tag_set tag_set;
>  };
>  
>  static unsigned int nr_minors;
> @@ -385,6 +390,7 @@ static int blkif_ioctl(struct block_device *bdev, fmode_t mode,
>   * and writes are handled as expected.
>   *
>   * @req: a request struct
> + * @ring_idx: index of the ring the request is to be inserted in

This comment addition doesn't seem to correspond with anything?

>   */
>  static int blkif_queue_request(struct request *req)
>  {
> @@ -632,6 +638,61 @@ wait:
>  		flush_requests(info);
>  }
>  
> +static int blkfront_queue_rq(struct blk_mq_hw_ctx *hctx, struct request *req)
> +{
> +	struct blkfront_info *info = req->rq_disk->private_data;
> +
> +	pr_debug("Entered blkfront_queue_rq\n");

I don't think this debug is useful.

> +	spin_lock_irq(&info->io_lock);

Is this lock necessary?  Does the block layer serialise calls to the
queue_rq op?

> +	if (RING_FULL(&info->ring))
> +		goto wait;
> +
> +	if ((req->cmd_type != REQ_TYPE_FS) ||
> +			((req->cmd_flags & (REQ_FLUSH | REQ_FUA)) &&
> +			 !info->flush_op)) {
> +		req->errors = -EIO;
> +		blk_mq_complete_request(req);
> +		spin_unlock_irq(&info->io_lock);
> +		return BLK_MQ_RQ_QUEUE_ERROR;
> +	}
> +
> +	pr_debug("blkfront_queue_req %p: cmd %p, sec %lx, ""(%u/%u) [%s]\n",
> +			req, req->cmd, (unsigned long)blk_rq_pos(req),
> +			blk_rq_cur_sectors(req), blk_rq_sectors(req),
> +			rq_data_dir(req) ? "write" : "read");

The block layer already has extensive tracing for requests.  Is this
debug useful?

> @@ -639,9 +700,29 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size,
>  	struct request_queue *rq;
>  	struct blkfront_info *info = gd->private_data;
>  
> -	rq = blk_init_queue(do_blkif_request, &info->io_lock);
> -	if (rq == NULL)
> -		return -1;
> +	if (hardware_queues) {

hardware_queues is never 0.  Is this if here and elsewhere necessary?

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/