On 3/18/2020 1:43 PM, Jason Gunthorpe wrote:
On Wed, Mar 18, 2020 at 09:52:27AM +0200, Yishai Hadas wrote:
We can really consider extending the functionality of a parent domain that
was just added for CQ in case it holds a thread domain for this purpose.
However, current code enforces creating a dedicated BF as part of thread
domain unless we extend ibv_alloc_td() to ask only for marking the single
thread functionality.
Doesn't the CQ need a BF too?
Not really, it uses a per-allocated device one for writing 8 bytes for
doorbell, applicable only in the arm/events mode.
In any event, I don't think it matters, any real application is likely
to use the thread domain with a QP as well so the BF will not be
wasted
Agree.
The existing alternative is or to use the legacy ENV that mentioned above or
to use the ibv_cq_ex functionality which upon its creation gets an explicit
flag for single threaded one (i.e. IBV_CREATE_CQ_ATTR_SINGLE_THREADED).
An apps that don't want the BF can always use
IBV_CREATE_CQ_ATTR_SINGLE_THREADED
This requires moving to the new polling mechanism where this option is
really applicable (see a3a31e8dc6a3fbf577dd8b12742d0c70cf63bd29).
I think consistency says that if a thread domain is passed into CQ it
should trigger IBV_CREATE_CQ_ATTR_SINGLE_THREADED
I would say, as of turning the general ENV of MLX5_SINGLE_THREADED but
only for this single CQ to support the legacy polling mode, the new one
has its own flag/flow in any case.
Yishai
