Re: RING_HAS_UNCONSUMED_REQUESTS oddness

[Zoltan Kiss <zoltan.kiss@citrix.com>]

On 12/03/14 10:28, Ian Campbell wrote:
> On Tue, 2014-03-11 at 23:24 +0000, Zoltan Kiss wrote:
>> On 11/03/14 15:44, Ian Campbell wrote:
>
>>> Is it the case that this macro considers a request to be unconsumed if
>>> the *response* to a request is outstanding as well as if the request
>>> itself is still on the ring?
>> I don't think that would make sense. I think everywhere where this macro
>> is called the caller is not interested in pending request (pending means
>> consumed but not responded)
>
> It might be interested in such pending requests in some of the
> pathological cases I allude to in the next paragraph though?
>
> For example if the ring has unconsumed requests but there are no slots
> free for a response, it would be better to treat it as no unconsumed
> requests until space opens up for a response, otherwise something else
> just has to abort the processing of the request when it notices the lack
> of space.
>
> (I'm totally speculating here BTW, I don't have any concrete idea why
> things are done this way...)
>
>
>>> I wonder if this apparently weird construction is due to pathological
>>> cases when one or the other end is not picking up requests/responses?
>>> i.e. trying to avoid deadlocking the ring or generating an interrupt
>>> storm when the ring it is full of one or the other or something along
>>> those lines?
>
>

Also, let me quote again my example about when rsp makes sense:

"To clarify what does this do, let me show an example:
req_prod = 253
req_cons = 256
rsp_prod_pvt = 0

req will be UINT_MAX-2, as the values changed in the meantime, and rsp 
is 0. It's reasonable to return 0 here, as the backend hasn't replied 
anything yet, so we clearly shouldn't have any unconsumed request in the 
ring."

Zoli