[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG53R5Vt+TTx8bm9+jyksBJ-nMh0Ug4wnhNicK7LsdqL+AGz_w@mail.gmail.com>
Date: Sun, 17 Jan 2016 16:39:33 +0530
From: Parav Pandit <pandit.parav@...il.com>
To: Sagi Grimberg <sagig@....mellanox.co.il>
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
On Sun, Jan 17, 2016 at 4:36 PM, Sagi Grimberg <sagig@....mellanox.co.il> wrote:
>
>>> 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.
o.k. Thanks.
Powered by blists - more mailing lists