[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <569B75C8.5010709@dev.mellanox.co.il>
Date: Sun, 17 Jan 2016 13:06:48 +0200
From: Sagi Grimberg <sagig@....mellanox.co.il>
To: Parav Pandit <pandit.parav@...il.com>
Cc: Christoph Hellwig <hch@....de>, linux-rdma@...r.kernel.org,
Bart Van Assche <bart.vanassche@...disk.com>, axboe@...com,
linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 07/13] IB: add a proper completion queue abstraction
>> If we have not drained the CQ (consumed budget or more) the second
>> condition (ib_req_notify_cq) will not be invoked. We are only rearming
>> the CQ when we drained it completely. So I don't see how we can end up
>> with missed notifications.
> We drain the CQ completely for whatever CQEs available at that time,
> say for example,
> 33 CQEs drained at time t1. So now req_notify_cq will be invoked at time t2.
> During time delta t2-t1, CQ in hardware remains unarmed.
> If cqes are added during that time delta, Will event/interrupt raised
> for it, for CQ in unarmed state?
>
> At time time t2, CQ is armed containing pending CQEs. Will
> event/interrupt raised for those pending CQEs on next arming?
If the device did not reported missed-events then it is the device
responsibility to generate a new completion event after arming.
Specifically, the mlx4/mlx5 HW is able to generate a completion event
in your described scenario. A device that is not capable of doing so
must report missed events to inform the core it has more completions
to consume.
Powered by blists - more mailing lists