Re: RING_HAS_UNCONSUMED_REQUESTS oddness

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

On 12/03/14 14:30, Ian Campbell wrote:
> On Wed, 2014-03-12 at 14:27 +0000, Zoltan Kiss wrote:
>> 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
>
> I think to make sense of this I need to see the sequence of reads/writes
> from both parties in a sensible ordering which would result in reads
> showing the above. i.e. a demonstration of the race not just an
> assertion that if the values are read as is things makes sense.

Let me extend it:

- callback reads req_prod = 253
- frontend writes req_prod, now its 256
- backend picks it up, and consumes those slots, req_cons become 256
- callback reads req_cons = 256
- req is UINT_MAX-3 therefore, but actually there isn't any request to 
consume, it should be 0
- callback reads rsp_prod_pvt = 0, because backend haven't responded to 
any requests
- rsp is therefore 256 - (256 -0) = 0
- the macro returns rsp, as it is smaller. And that's good, because 
despite the macro failed to determine the number of unconsumed requests, 
at least it detected that the ring is full with consumed but not replied 
requests, so there shouldn't be any unconsumed req

And I call this best effort because if rsp_prod_pvt is e.g. 10, rsp will 
be then 10 as well, we return it, and the caller thinks there are 
unconsumed requests, despite there isn't any.

Zoli