submit_and_wait always calls atomic::fence(atomic::Ordering::SeqCst) when the kernel is configured to use sqpoll.
So it might be faster to keep an eye on the clock (in our code), and only call submit if, say, it's been at least 800 ms since we last added to the SQ. (And only do this if our code uses sqpoll). But, as always, I should benchmark!
Implementation
I could use crossbeam::channel::after. But supposedly that also requires an atomic load. So it might just be faster to do the simple thing and check the time on every iteration! I probably want to wrap the submission queue in my own type, which will also look after waking the SQ (if enough time has elapsed, and if we're actually using sqpoll!)
submitcallssubmit_and_wait.submit_and_waitalways callsatomic::fence(atomic::Ordering::SeqCst)when the kernel is configured to use sqpoll.So it might be faster to keep an eye on the clock (in our code), and only call
submitif, say, it's been at least 800 ms since we last added to the SQ. (And only do this if our code uses sqpoll). But, as always, I should benchmark!Implementation
I could use
crossbeam::channel::after. But supposedly that also requires an atomic load. So it might just be faster to do the simple thing and check the time on every iteration! I probably want to wrap thesubmissionqueue in my own type, which will also look after waking the SQ (if enough time has elapsed, and if we're actually using sqpoll!)Related