On 05/09/17 20:54, Ulf Hansson wrote:

On 5 September 2017 at 10:10, Adrian Hunter [off-list ref] wrote:

quoted

On 05/09/17 10:24, Ulf Hansson wrote:

quoted

[...]

quoted

quoted

quoted

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!