[lkml]   [2015]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/9] IB: add a proper completion queue abstraction
On Tue, Nov 17, 2015 at 09:52:58AM -0800, Bart Van Assche wrote:
> On 11/13/2015 05:46 AM, Christoph Hellwig wrote:
>> + * context and does not ask from completion interrupts from the HCA.
> ^^^^
> Should this perhaps be changed into "for" ?


>> + */
>> +void ib_process_cq_direct(struct ib_cq *cq)
>> +{
>> + WARN_ON_ONCE(cq->poll_ctx != IB_POLL_DIRECT);
>> +
>> + __ib_process_cq(cq, INT_MAX);
>> +}
>> +EXPORT_SYMBOL(ib_process_cq_direct);
> My proposal is to drop this function and to export __ib_process_cq()
> instead (with or without renaming). That will allow callers of this
> function to compare the poll budget with the number of completions that
> have been processed and use that information to decide whether or not to
> call this function again.

I'd like to keep the WARN_ON, but we can export the same signature.

Then again my preference would be to remove the direct mode entirely.

>> +static void ib_cq_completion_workqueue(struct ib_cq *cq, void *private)
>> +{
>> + queue_work(ib_comp_wq, &cq->work);
>> +}
> The above code will cause all polling to occur on the context of the CPU
> that received the completion interrupt. This approach is not powerful
> enough. For certain workloads throughput is higher if work completions are
> processed by another CPU core on the same CPU socket. Has it been
> considered to make the CPU core on which work completions are processed
> configurable ?

It's an unbound workqueue, so it's not tied to the specific CPU. However
we'll only run the work_struct once so it's still tied to a single CPU
at a time, but that's not different from the kthread use previously.

 \ /
  Last update: 2015-11-18 15:21    [W:0.135 / U:1.876 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site