Thank you so much.
I think I have found the reson. But I cannot understand the logic of that code.
In the Context::enqueue_drq method, there is a piece of code to determin if IPI is needed.
if (!_pending_rq.queued())
{
if (!q.first())
ipi = true;
q.enqueue(&_pending_rq);
}
In my understanding, the logic behind this is to check if _pending_rq is queued first, if it is queued, it's done; else enqueue it.
And check if the queue is empty. If it is empty, IPI is needed, else this request can be picked up by IPI of other request.
The problem is I cannot image in what case the _pending_rq is already queued, at least in my program.
My scenario is: there is only one client and one server in different core, and client sends ipc in a tight loop. I think each time the server receives the request, it should dequeue _pending_rq, so it is not possible for client to see the _pending_rq is queued when it wants to ipc.But I observed this indeed happan sometime.
I hope I descibe my question clearly.
Could you give me some hints?
Best,
Yuxin