Re: [PATCH v2 0/3] new ib_drain_qp() API

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]

On 02/10/2016 10:27 AM, Steve Wise wrote:
>>>>> Hello Steve,
>>>>>
>>>>> How about creating three functions - one that drains the receive queue,
>>>>> one that drains the send queue and a third function that drains both ?
>>>>> The latter function then can call the two former functions. And since
>>>>> only one of these three functions will have a user in your patch series
>>>>> (the function that drains the RQ), how about only introducing only that
>>>>> function now and to wait with introducing the two other functions until
>>>>> these have a user ?
>>>>
>>>> That sounds reasonable.  Simpler too perhaps.  We'll see if anyone else
>>>> has an opinion.
>>>
>>> Another option is for ib_drain_qp() to just skip queues with IB_POLL_DIRECT CQ processing.
>>
>> I'd rather not skip silently anything. ib_drain_qp() semantics is that
>> it drains all the pending posts on the queue-pair (i.e. both send and
>> receive queues).
>>
>> We can split to send and receive, but the fact that srp uses direct
>> polling CQ is not sufficient for that, most if not all will benefit from
>> both.
>>
> 
> If we split it into ib_drain_rq(), ib_drain_sq(), and ib_drain_qp(), then srp would only call ib_drain_rq().  Others can call
> ib_drain_qp() if they want both SQ and RQ drained.

I'm in favor of this kind of flexibility at the API level.


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]