[...] >>>>> + >>>>> +enum mmc_issued mmc_blk_mq_issue_rq(struct mmc_queue *mq, struct request *req) >>>>> +{ >>>>> + struct mmc_blk_data *md = mq->blkdata; >>>>> + struct mmc_card *card = md->queue.card; >>>>> + struct mmc_host *host = card->host; >>>>> + int ret; >>>>> + >>>>> + ret = mmc_blk_part_switch(card, md->part_type); >>>> >>>> What if there is an ongoing request, shouldn't you wait for that to >>>> complete before switching partition? >>> >>> Two requests on the same queue cannot be on different partitions because we >>> have a different queue (and block device) for each partition. >> >> That's not true for RPMB anymore I am afraid. >> >> RPMB shares the same queue as for the main eMMC partition, which is >> because we strive towards fair I/O scheduling across the hole device. > > I hadn't thought of RPMB, but I think the logic is OK, which is good because > it is the same as we presently have. Here the md->part_type will be the > main area even for RPMB. So this switch won't do anything if we have a > request in flight. Then inside __mmc_blk_ioctl_cmd() the switch to RPMB is > done, and afterwards mmc_blk_issue_drv_op() switches it back again. Yes, you are right! No worries then! [...] >>> >>> You are right, this logic does not support parallel dispatches. >>> >> >> This do raises a question, don't you think it would be beneficial, >> especially for CQE to allow parallel dispatches? >> >> I am not saying we should change this at this point, just that we may >> consider changing this for future improvements. > > I think the benefit is limited because the time to dispatch a request is > small compared with the time to complete a request. i.e. a number of > requests can be queued before the first one has completed. But yes, it is > something to keep in mind. Yeah, let's leave this for future considerations. 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