Re: [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path?

[Hannes Reinecke <hare@suse.de>]

On 01/13/2016 12:39 AM, Mikulas Patocka wrote:
>
>
> On Tue, 12 Jan 2016, Mike Snitzer wrote:
>
>> Hi,
>>
>> I'd like to attend LSF/MM and as the subject covers I'd like to at least
>> participate in a discussion about plans (realistic or not) for
>> removing/deprecating the old .request_fn path in block core and block
>> drivers.
>>
>> The request-based DM code (only used for multipath) has gotten more
>> complex to support both old .request_fn and blk-mq (and stacking
>> combinations: .request_fn ontop of blk-mq paths, blk-mq ontop of
>> .request_fn paths).  Simplifying DM core in this area would be nice.
>>
>> One of the hurdles has been blk-mq doesn't yet have a scheduler.  I know
>> Jens had/has something in the works.  But there is also the question of
>> whether DM's top-level blk-mq request_queue should be trained to
>> leverage/stack underlying blk-mq request_queue capabilities (Keith Busch
>> was going to look at this aspect in the context of multipath on NVMe but
>> I never heard anything from Keith on that).  As of now DM multipath's
>> blk-mq request_queue only supports a single (virtual) hw queue.
>>
>> In addition to the above topic, I'd be open to discussing Linux MD
>> maintainership options with others if for some reason that is still an
>> unresolved situation come mid April.
>>
>> Thanks,
>> Mike
>
> Convert multipath from request-based to bio-based and these problems in
> device mapper core will disappear :-)
>
We have been down that road already. It doesn't work.
There is a reason why we switched to request-based multipathing.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)