On Fri, Jan 31, 2020 at 04:53:41PM -0800, Satya Tangirala wrote: > So I tried reading through more of blk-mq and the IO schedulers to figure > out how to do this. As far as I can tell, requests may be merged with > each other until they're taken off the scheduler. So ideally, we'd > program a keyslot for a request when it's taken off the scheduler, but > this happens from within an atomic context. Otoh, programming a keyslot > might cause the thread to sleep (in the event that all keyslots are in use > by other in-flight requests). Unless I'm missing something, or you had some > other different idea in mind, I think it's a lot easier to stick to letting > blk-crypto program keyslots and manage them per-bio... But as far as I understand from reading the code it only sleeps because it waits for another key slot to be released. Which is exactly like any other resource constraint in the storage device. In that case ->queue_rq returns BLK_STS_RESOURCE (or you do the equivalent in the blk-mq code) and the queue gets woken again once the resource is available.
