On Wed, 2018-01-10 at 17:00 +0000, Andrey Kuzmin wrote: > > > On Wed, Jan 10, 2018, 19:47 Luse, Paul E wrote: > > So I'll take the easy way out and just ask.. what's the most efficient way > > for an app, designed just this one for whatever reason, essentially > > relinquish control to the event reactor - is there a single call he can slip > > into the loop to give other pending events, if any a chance to run and if > > not continue on submitting? > > It appears quite logical to start submission with a check for pending > completions, doesn't it? Or check for completions if downstream bdev returns > busy status. That would definitely meet app expectations whatever the request > pool size is. We've considered checking for completions inside the submission path if we would otherwise return ENOMEM. So far, we've decided not to go that direction for two reasons. 1) Even if we do this, there are still cases where we'll return ENOMEM. For instance, if there are no completions to reap yet. 2) This would result in completion callbacks in response to a submit call. Today, the expectations are set that completions are called in response to a poll call only.