On Mon, 9 Sep 2019 at 20:45, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > > On 9/09/19 3:16 PM, Baolin Wang wrote: > > Hi Adrian, > > > > On Mon, 9 Sep 2019 at 20:02, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > >> > >> On 6/09/19 6:52 AM, Baolin Wang wrote: > >>> Now the MMC read/write stack will always wait for previous request is > >>> completed by mmc_blk_rw_wait(), before sending a new request to hardware, > >>> or queue a work to complete request, that will bring context switching > >>> overhead, especially for high I/O per second rates, to affect the IO > >>> performance. > >>> > >>> Thus this patch introduces virtual command queue interface, which is > >>> similar with the hardware command queue engine's idea, that can remove > >>> the context switching. > >> > >> CQHCI is a hardware interface for eMMC's that support command queuing. What > >> you are doing is a software issue queue, unrelated to CQHCI. I think you > > > > Yes. > > > >> should avoid all reference to CQHCI i.e. call it something else. > > > > Since its process is similar with CQHCI and re-use the CQHCI's > > interfaces, I called it virtual command queue. I am not sure what else > > name is better, any thoughts? VCQHCI? Thanks. > > What about swq for software queue. Maybe Ulf can suggest something? Um, though changing to use swq, still need reuse command queue's interfaces, like 'mq->use-cqe', 'host->cqe_depth' and cqe ops and so on, looks a little weird for me. But if you all agree with this name, then I am okay. Ulf, what do you suggest? -- Baolin Wang Best Regards
