On 6/16/24 2:39 AM,, Jens Axboe wrote: >On 6/13/24 2:07 AM, Christoph Hellwig wrote: >>> We happily allow polled IO for async polled IO, even if the destination >>> queue isn't polled (or it doesn't exist). This is different than the old >>> sync polled support. >> >> Yes, and for that to work we can't start returning -EOPNOTSUPP as in >> this patch, as BLK_QC_T_NONE an be cleared for all kinds of reasons. >> >> So if we want some kind of error handling that people don't even >> bother to poll for devices where it is not supported we need that >> check much earlier (probably in io_uring). > >There's just no way we can do that, who knows if you'll run into a >polled queue or not further down the stack. > >IMHO there's nothing wrong with the current code. If you do stupid >things (do polled IO without having polled queues), then you get to >collect stupid prizes (potentially excessive CPU usage). I think the problem is that when the user makes this incorrect configuration, but doesn't have any error feedback, user is unware and easy to get some wrong performance information. So I hope to add some feedback for the user to help them more easily modify the configuration. I got your point, therefore, I'm considering whether it would be more resonable to not return -EOPNOTSUPP directly to stop the operation. Instead, we could detect this information and provide a prompt (like warining?), allowing user to be aware without disrupting the original flow. Do you think this approach is more reasonable?
