[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 07/03/14 12:02, Wei Liu wrote:
On Thu, Mar 06, 2014 at 09:39:40PM +0000, Zoltan Kiss wrote:
On 06/03/14 17:30, Tim Deegan wrote:
At 16:31 +0000 on 06 Mar (1394119880), Zoltan Kiss wrote:
On 06/03/14 15:53, Ian Campbell wrote:
On Thu, 2014-03-06 at 15:47 +0000, Zoltan Kiss wrote:
By my understanding, there is no way rsp could be smaller than req, so
there is no point having this. Am I missing something?

It happens during wraparound, i.e. after req has wrapped but rsp hasn't

The name of the macro suggest we are interested whether the ring has
unconsumed requests, and netback uses it that way. The answer to that
question is req_prod - req_cons. And it works if prod wrapped but cons


rsp calculates the number of "consumed but not responded" requests (it
also works well if req_cons wrapped but rsp_prod_pvt didn't), then
subtract it from the ring size.

That is indeed an odd thing to check, since it seems like it could only
be relevant if the request producer overran the response producer.
It's been there in one form or another since the original ring.h,
and RING_REQUEST_CONS_OVERFLOW does something similar.

I can't remember the original reasoning, and so I'm reluctant to
suggest removing it without some more eyes on the code...

I've added the following printk before the "req < rsp" part:

        if (rsp < req)                                                       \
                pr_err("req %u rsp %u req_prod %u req_cons %u rsp_prod_pvt 
req, rsp, (_r)->sring->req_prod, (_r)->req_cons,
(_r)->rsp_prod_pvt); \

And it gave me such results:

xen_netback:xenvif_zerocopy_callback: req 4294967279 rsp 52 req_prod
1770663942 req_cons 1770663959 rsp_prod_pvt 1770663755

So it can happen that req_prod is behind req_cons, sometimes even
with 17! But it always happen in this callback of my new grant
mapping series, which runs outside the NAPI instance. My theory why
this can happen:
- callback reads req_prod
- frontend writes it
- backend picks it up, and consumes those slots
- callback reads req_cons

So there's three parties accessing the ring? I *think* the ring is only
designed to be lockfree for two parties so I don't know whether this
model is legit.
Indeed, however if we want to reintroduce grant mapping in netback, the releasing of pages will happen asynchronously. And there, you have to check whether you should kick the NAPI instance, to avoid this kind of stall: - xenvif_poll call napi_complete, because more_to_do=true, but xenvif_tx_pending_slots_available=false
- we won't receive interrupt from frontend, as we already got one
- the reasonable place to kick in NAPI instance is when we released packets. Fortunately it doesn't happen very often

Actually at the moment I do it in the callback, but it's better in the dealloc thread, when we really released the pending slots, otherwise we might risk that NAPI instance quickly deschedule itself again. I'll fix that in a next series

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.