On 9/3/20 10:44 AM, Kashyap Desai wrote: >> 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. Great, thanks. >>> 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. This is exactly what I meant, just wanted to ensure it wasn't the poor mans edition that we've seen before, we're IRQs are still triggered and you end up getting completions from both manual finding via the poll hook, and from the "normal" side. Because that kind of sucks. What you have sounds exactly how it should be, both in terms of functionality and implementation. Thanks for confirming! Guess I need to take another look at the shared host tag set support, see if we an get that in for 5.10. -- Jens Axboe
