OK yeah that makes sense, one could experiment with batching some number of requests and counting through callbacks to find a good number to submit before returning, was hoping for something like spdk_yield_thread() but of course didn't look first.  Do you think that might be useful or has this never come up before? 

Thx
Paul

-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Walker, Benjamin
Sent: Wednesday, January 10, 2018 9:58 AM
To: freeman.zhang1992(a)gmail.com; spdk(a)lists.01.org
Subject: Re: [SPDK] Problem with Blobstore when write 65MB continously

On Wed, 2018-01-10 at 16:47 +0000, Luse, Paul E wrote:
> Damn, I should have known that :( Thanks guys!! 
> 
> 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?

Return from the function submitting I/O after submitting a certain number and resume submitting new I/O in response to completion callbacks.

> 
> Thx
> Paul
> 
> -----Original Message-----
> From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Walker, 
> Benjamin
> Sent: Wednesday, January 10, 2018 9:33 AM
> To: freeman.zhang1992(a)gmail.com; spdk(a)lists.01.org
> Subject: Re: [SPDK] Problem with Blobstore when write 65MB continously
> 
> On Wed, 2018-01-10 at 16:21 +0000, Harris, James R wrote:
> > Hi Paul and Zhengyu,
> > 
> > The problem is that the app is not giving the block device a chance 
> > to complete any I/O while submitting the 520 back-to-back requests.
> > Blobstore is passive here – it does not do any polling on the block 
> > device – that is up to the application.
> 
> To additionally clarify - the bdev layer will poll for completions on 
> your behalf, but it does so on the same thread that you are submitting 
> I/O from. If you are in a tight loop submitting I/O and never yield 
> back to the event reactor, the polling won't have a chance to occur. 
> You can either increase the number of reqs per channel or submit 
> smaller batches at a time. Basically, do what Jim said below.
> 
> > Increasing the number of channel reqs would work – but at some point 
> > these will still run out.  So it really depends on your application 
> > – either increase the channel reqs to the absolutely maximum you 
> > will ever need, or add ENOMEM handling.
> 
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk
_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk