[PATCH v3 0/9] Introduce per-device completion queue pools

Sagi Grimberg sagi at grimberg.me
Mon Nov 13 12:31:26 PST 2017


>> But I'm afraid don't understand how the fact that ULPs will run on
>> different ports matter? how would the fact that we had two different
>> pools on different ports make a difference?
> 
> If each RDMA port is only used by a single ULP then the ULP driver can provide
> a better value for the CQ size than IB_CQE_BATCH. If CQ pools would be created
> by ULPs then it would be easy for ULPs to pass their choice of CQ size to the
> RDMA core.

But if that is not the case, maybe we may have less completion
aggragation per interrupt.

> In case multiple ULPs share an RDMA port then which CQ is chosen for the ULP
> will depend on the order in which the ULP drivers are loaded. This may lead to
> hard to debug performance issues, e.g. due to different lock contention
> behavior. That's another reason why per-ULP CQ pools look more interesting to
> me than one CQ pool per HCA.

The ULP is free to pass in an affinity hint to enforce locality to a
specific cpu core. Would that solve this issue?



More information about the Linux-nvme mailing list