On 5 September 2017 at 10:10, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > On 05/09/17 10:24, Ulf Hansson wrote: >> [...] >> >>>>> >>>>> I can send blk-mq support for legacy requests in a few days if you like, but >>>>> I want to hear a better explanation of why you are delaying CQE support. >>>> >>>> That would be very nice, however be aware of that we are in the merge >>>> window, so I am not picking new material for 4.14 from this point. I >>>> assume you understand why. >>> >>> Nope. This is new functionality - doesn't affect anyone who doesn't have a >>> command queue engine. Next to no chance of regressions. Tested by several >>> in the community. Substantially unchanged since February. It is not even >>> very much code in the block driver. >> >> Let me make it clear, once more - I don't want to maintain more hacks >> in mmc block layer code. >> >> This series add blkmq support, using a method (which may be considered >> as intermediate) via a new change in patch1 - but only for the new CQE >> path. That means the old legacy mmc block path is still there. So, for >> the reason stated above - no thanks! > > And where is your alternative. When I pointed out you need a way to > arbitrate between internal partitions, you went silent again. > > Can't have CQE without blk-mq but can't have blk-mq because you don't > understand it, is hardly acceptable. Adrian, this discussion seems to lead nowhere. Can we please stop and be constructive instead! Regarding the arbitration issue. We have been moving forward, re-factoring the mmc block driver code, soon also solving the problem for the rpmb internal partition [1]. Maybe the background to why Linus is working on mmc block re-factoring, hasn't been entirely clear. Anyway, it's exactly because of moving closer to address these issues. Even if the problems certainly becomes a step harder to resolve for the boot and the general purpose partitions, it's still a path we should try to find a solution for. Yeah, that may mean we need to suggest changes for the generic block layer, to teach it to better deal with these kind of devices. Finally, I have never said the arbitration issue *must* be solved before converting to blkmq. Only that we should avoid performance regressions, but that of course applies to whatever changes we do. [...] Kind regards Uffe [1] https://patchwork.kernel.org/patch/9911463/
