All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: "Jens Axboe" <axboe@kernel.dk>, "Hannes Reinecke" <hare@suse.com>,
	"Sagi Grimberg" <sagi@grimberg.me>,
	"Javier González" <javier@cnexlabs.com>,
	dm-devel@redhat.com, "Christoph Hellwig" <hch@lst.de>
Subject: Re: fold direct_make_requst into generic_make_request
Date: Mon, 26 Feb 2018 19:13:28 -0500	[thread overview]
Message-ID: <20180227001328.GA15748@redhat.com> (raw)
In-Reply-To: <alpine.LRH.2.02.1802261524090.5096@file01.intranet.prod.int.rdu2.redhat.com>

On Mon, Feb 26 2018 at  5:56pm -0500,
Mikulas Patocka <mpatocka@redhat.com> wrote:

> The block layer provides a function direct_make_request - but it doesn't
> provide any test whether this function may be used or not.
> 
> Device mapper currently uses a dirty trick - it compares the result of
> bdevname against the string "nvme" to test if direct_make_request can be
> used.

dm's DM_TYPE_NVME_BIO_BASED is backed by that crude "nvme" check _but_
it is a means to an end.  Alternative would be to have NVMe (and other
devices) set something like QUEUE_FLAG_NO_PARTIAL_COMPLETION or
something -- and then DM would need to verify all underlying devices set
that flag.

> The information whether the driver will or won't recurse can be easily
> obtained in generic_make_request (by comparing make_request_fn - or
> alternatively, we could introduce a queue flag for this), so my suggestion
> is to just delete direct_make_request and fold this "norecurse"
> optimization directly into generic_make_request This will allow us to
> simplify device mapper paths and get rid of device name matching.

Sorry, Nack from me as implemented.  Please see below.

> Index: linux-2.6/block/blk-core.c
> ===================================================================
> --- linux-2.6.orig/block/blk-core.c	2018-02-26 20:37:19.088499000 +0100
> +++ linux-2.6/block/blk-core.c	2018-02-26 20:43:57.839999000 +0100
> @@ -2265,6 +2265,8 @@ end_io:
>  	return false;
>  }
>  
> +blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio);
> +
>  /**
>   * generic_make_request - hand a buffer to its device driver for I/O
>   * @bio:  The bio describing the location in memory and on the device.
> @@ -2300,10 +2302,14 @@ blk_qc_t generic_make_request(struct bio
>  	 */
>  	struct bio_list bio_list_on_stack[2];
>  	blk_qc_t ret = BLK_QC_T_NONE;
> +	bool may_recurse;
>  
>  	if (!generic_make_request_checks(bio))
>  		goto out;
>  
> +	may_recurse = bio->bi_disk->queue->make_request_fn != blk_queue_bio &&
> +		      bio->bi_disk->queue->make_request_fn != blk_mq_make_request;
> +

This does _not_ allow dm's DM_TYPE_NVME_BIO_BASED to make use of your
direct_make_request() equivalent that you've encoded into
generic_make_request().

There is no easy way to _know_, at runtime, that an arbitrary queue
(e.g. stacked DM device) does _not_ split IO (therefore not needing to
recurse).

Same can be said of NVMe given NVMe multipath sets its make_request_fn
to nvme_ns_head_make_request().

So for both cases that don't need to recurse you're setting @may_recurse
to true.

As such, this patch is not equivalent to what we have now.

Mike

  reply	other threads:[~2018-02-27  0:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-26 22:56 [PATCH] fold direct_make_requst into generic_make_request Mikulas Patocka
2018-02-27  0:13 ` Mike Snitzer [this message]
2018-02-27  0:58   ` Mike Snitzer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180227001328.GA15748@redhat.com \
    --to=snitzer@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=dm-devel@redhat.com \
    --cc=hare@suse.com \
    --cc=hch@lst.de \
    --cc=javier@cnexlabs.com \
    --cc=mpatocka@redhat.com \
    --cc=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.