On Thu, Dec 21, 2017 at 03:17:41PM -0700, Jens Axboe wrote: > On 12/21/17 2:34 PM, Keith Busch wrote: > > It would be nice, but the driver doesn't know a request's completion > > is going to be a polled. > > That's trivially solvable though, since the information is available > at submission time. > > > Even if it did, we don't have a spec defined > > way to tell the controller not to send an interrupt with this command's > > compeletion, which would be negated anyway if any interrupt driven IO > > is mixed in the same queue. We could possibly create a special queue > > with interrupts disabled for this purpose if we can pass the HIPRI hint > > through the request. > > There's on way to do it per IO, right. But you can create a sq/cq pair > without interrupts enabled. This would also allow you to scale better > with multiple users of polling, a case where we currently don't > perform as well spdk, for instance. Would you be open to have blk-mq provide special hi-pri hardware contexts for all these requests to come through? Maybe one per NUMA node? If not, I don't think have enough unused bits in the NVMe command id to stash the hctx id to extract the original request.
