From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============1195509196208086586==" MIME-Version: 1.0 From: Walker, Benjamin Subject: Re: [SPDK] Problem with Blobstore when write 65MB continously Date: Wed, 10 Jan 2018 17:17:16 +0000 Message-ID: <1515604634.6063.43.camel@intel.com> In-Reply-To: CANvN+e=0WFUQPchg+KebVNT+4hrcee7yq9DzeRUc6i7d9VnNiA@mail.gmail.com List-ID: To: spdk@lists.01.org --===============1195509196208086586== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 retu= rns > busy status. That would definitely meet app expectations whatever the req= uest > 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. --===============1195509196208086586==--