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@xxxxxxxxxx>
GPG KeyID: 0E572FDD
Attachment:
signature.asc
Description: OpenPGP digital signature
