<sorry for delay, i was out>

On Wed, Aug 10, 2016 at 01:31:21PM -0400, Sinan Kaya wrote:

On 8/10/2016 1:28 PM, Vinod Koul wrote:

quoted

quoted

That's why, I preferred not to call the callback when I observe an error which I

quoted

think it makes more sense. 

That doesnt make sense. A client set a callback, it expect you to call one.
The result quried maybe txn completed or error. Since you have means, please
report..

If there is a good way to fix tx_status, I can certainly do so. I just need to make
sure my implementation is robust and reliable.

I saw your reply that we need to keep this information around until terminate_all is
called. 

What is a good implementation strategy?

Keep a size limited list with error cookies and flush them in terminate all?

I think so, terminate_all anyway cleans up the channel. Btw what is the
behaviour on error? Do you terminate or somthing else?

What should I do if code reaches to the size limit?

Size the error cookie list double the size of available descriptors?

That won't help as you would have two values per cookie and we dont want
that :)

quoted

quoted

Again, it will be a different patch than this one. I think v2 of this patch

quoted

needs to go in as it is.

https://lkml.org/lkml/2016/7/31/64

I havent looked at the patch. If it is not invoking callback set by user,
then I am not taking it. Sorry, we dont choose over client's wish.

Ok. The problem you are referring to is something else and needs to be addressed
separately. I can create a series with first implement a reliable tx_status based
on your recommendation above.

Then, change the current behavior so that client callback is always executed as you
requested.

After that this patch to fix the free order.

-- 
~Vinod