On 06/09/17 12:54, Ulf Hansson wrote: > 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. Which is unreasonable and unacceptable. > End of discussion! Hardly. I plan to submit blk-mq patches in a few days and I expect a proper response. Not silence. Not "consensus". And especially not "we want to do it a different way but we don't know what that is". -- 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
