[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5651F39A.2020003@acm.org>
Date: Sun, 22 Nov 2015 08:55:54 -0800
From: Bart Van Assche <bvanassche@....org>
To: Sagi Grimberg <sagig@....mellanox.co.il>,
Christoph Hellwig <hch@....de>
Cc: "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"axboe@...com" <axboe@...com>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/9] IB: add a proper completion queue abstraction
On 11/22/15 06:57, Sagi Grimberg wrote:
>>> I think that bart wants to allow the caller to select cpu affinity
>>> per CQ. In this case ib_alloc_cq in workqueue mode would need to
>>> accept a affinity_hint from the caller (default to wild-card
>>> WORK_CPU_UNBOUND).
>>
>> Hmm, true. How would be set that hint from userspace? I'd really prefer
>> to see a practical justification for it first.
>
> In order to assign CPUs from user-space we'd need an ethtool like
> interface for isert/srpt/<xxxt>. Given that this is something we don't
> want to get into right now, I assumed that Bart meant that srpt
> would take a "least used" approach from srpt driver (which isn't better
> taking the wild-card option I'd say), So I'll let Bart answer...
Hello Christoph and Sagi,
My intention is indeed to allow to control CPU affinity per CQ. One use
case is to implement a least-used policy in RDMA drivers that use
multiple completion queues. Another use case is to make CPU affinity
configurable from user space through something similar to ethtool or via
sysfs.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists