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.
I strongly agree we can do better here. Initial measurements of request-based DM multipath over the (soon to come) nvme-loop driver shows improvement from the bio-based code, but instrumentation reveals we have plenty of room for improvement. -- 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
