• Mike Snitzer's avatar
    dm: allocate requests in target when stacking on blk-mq devices · e5863d9a
    Mike Snitzer authored
    For blk-mq request-based DM the responsibility of allocating a cloned
    request is transfered from DM core to the target type.  Doing so
    enables the cloned request to be allocated from the appropriate
    blk-mq request_queue's pool (only the DM target, e.g. multipath, can
    know which block device to send a given cloned request to).
    
    Care was taken to preserve compatibility with old-style block request
    completion that requires request-based DM _not_ acquire the clone
    request's queue lock in the completion path.  As such, there are now 2
    different request-based DM target_type interfaces:
    1) the original .map_rq() interface will continue to be used for
       non-blk-mq devices -- the preallocated clone request is passed in
       from DM core.
    2) a new .clone_and_map_rq() and .release_clone_rq() will be used for
       blk-mq devices -- blk_get_request() and blk_put_request() are used
       respectively from these hooks.
    
    dm_table_set_type() was updated to detect if the request-based target is
    being stacked on blk-mq devices, if so DM_TYPE_MQ_REQUEST_BASED is set.
    DM core disallows switching the DM table's type after it is set.  This
    means that there is no mixing of non-blk-mq and blk-mq devices within
    the same request-based DM table.
    
    [This patch was started by Keith and later heavily modified by Mike]
    Tested-by: default avatarBart Van Assche <bvanassche@acm.org>
    Signed-off-by: default avatarKeith Busch <keith.busch@intel.com>
    Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
    e5863d9a
dm-target.c 3.02 KB