On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote:
> @@ -2188,11 +2327,18 @@ enum mmc_issued mmc_blk_mq_issue_rq(struct mmc_queue *mq, struct request *req)
> return MMC_REQ_FAILED_TO_START;
> }
> return MMC_REQ_FINISHED;
> + case MMC_ISSUE_DCMD:
> case MMC_ISSUE_ASYNC:
> switch (req_op(req)) {
> + case REQ_OP_FLUSH:
> + ret = mmc_blk_cqe_issue_flush(mq, req);
> + break;
> case REQ_OP_READ:
> case REQ_OP_WRITE:
> - ret = mmc_blk_mq_issue_rw_rq(mq, req);
> + if (mq->use_cqe)
> + ret = mmc_blk_cqe_issue_rw_rq(mq, req);
> + else
> + ret = mmc_blk_mq_issue_rw_rq(mq, req);
> break;
> default:
> WARN_ON_ONCE(1);
This and other bits gives me the feeling CQE is now actually ONLY
working on the MQ path.
That is good. We only add new functionality on the MQ path,
yay!
But this fact (only abailable iff MQ==true) should at least be
mentioned in the commit message I think?
So why not ditch the old block layer or at least make MQ default?
When you keep it like this people have to reconfigure
their kernel to enable MQ before they see the benefits of MQ+CQE
combined, I think that should rather be the default experience.
Yours,
Linus Walleij
--
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
