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 :-) Mikulas -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
