On 6 September 2017 at 09:20, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > On 05/09/17 20:54, Ulf Hansson wrote: >> 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! > > If you want to be constructive you will queue CQE support for v4.15 now! > >> >> 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. > > Nope, wrt blk-mq you are moving sideways with no clear idea where you're going. > >> 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. > > You mean you have no idea how to do it but we are still expected to wait. > How is that acceptable! > >> 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. > > Then there is no problem in queuing up the CQE patches now! Either you are not paying attention or just being grumpy. So for the last time, I don't want to pick CQE, prior the existing mmc block code has converted to blkmq. End of discussion! Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
