> On 9/3/20 10:14 AM, Kashyap Desai wrote: > > Currently io_uring support is only available in the block layer. > > This RFC is to extend support of mq_poll in the scsi layer. > > I think this needs to clarify that io_uring with IOPOLL is not currently > supported, outside of that everything else should work and no extra > support > in the driver is needed. > > The summary and title makes it sound like it currently doesn't work at > all, > which obviously isn't true! I actually mean io_uring with IOPOLL support. I will fix this. > > > megaraid_sas and mpt3sas driver will be immediate users of this > > interface. > > Both the drivers can use mq_poll only if it has exposed more than one > > nr_hw_queues. > > Waiting for below changes to enable shared host tag support. > > Just a quick question, do these low level drivers support non-irq mode for > requests? That's a requirement for IOPOLL support to work well, and I > don't > think it'd be worthwhile to plumb anything up that _doesn't_ support pure > non-IRQ mode. That's identical to the NVMe support, we will not allow > IOPOLL if you don't have explicit non-IRQ support. I guess you mean non-IRQ mode = There will not be any msix vector associated for poll_queues and h/w can still work in this mode. If above is correct, yes both the controller can support non-IRQ mode, but we need support of shared host tag as well for completeness of this feature in driver. Both the h/w are single submission queue and multiple reply queue, but using shared host tagset support we will enable simulated multiple hw queue. I have megaraid_sas driver patch available and it does identical to what NVME driver does. Driver allocates some extra reply queues and it will be marked as poll_queue. This poll_queue will not have associated msix vectors. All the IO completion on this queue will be done from IOPOLL interface. I tested megaraid_sas driver having 8 poll_queues and using io_uring hiprio=1 settings. It can reach 3.2M IOPs and there is *zero* interrupt. This is what NVME does so I assume this is what you wanted to confirm here. > > Outside of that, no comments on this enablement patch, looks pretty > straight > forward and fine to me. Thanks for review. > > -- > Jens Axboe
