Re: [PATCH] blk-mq-rdma: remove queue mapping helper for rdma devices

[Sagi Grimberg <sagi@grimberg.me>]

>>>>>> No rdma device exposes its irq vectors affinity today. So the only
>>>>>> mapping that we have left, is the default blk_mq_map_queues, which
>>>>>> we fallback to anyways. Also fixup the only consumer of this helper
>>>>>> (nvme-rdma).
>>>>>
>>>>> This was the only caller of ib_get_vector_affinity() so please delete
>>>>> op get_vector_affinity and ib_get_vector_affinity() from verbs as well
>>>>
>>>> Yep, no problem.
>>>>
>>>> Given that nvme-rdma was the only consumer, do you prefer this goes from
>>>> the nvme tree?
>>>
>>> Sure, it is probably fine
>>
>> I tried to do it two+ years ago:
>> https://lore.kernel.org/all/20200929091358.421086-1-leon@kernel.org
> 
> Christoph's points make sense, but I think we should still purge this
> code.
> 
> If we want to do proper managed affinity the right RDMA API is to
> directly ask for the desired CPU binding when creating the CQ, and
> optionally a way to change the CPU binding of the CQ at runtime.

I think the affinity management is referring to IRQD_AFFINITY_MANAGED
which IIRC is the case when the device passes `struct irq_affinity` to
pci_alloc_irq_vectors_affinity.

Not sure what that has to do with passing a cpu to create_cq.

> This obfuscated 'comp vector number' thing is nonsensical for a kAPI -
> creating a CQ on a random CPU then trying to backwards figure out what
> CPU it was created on is silly.

I don't remember if the comp_vector maps 1x1 to an irq vector, and if it
isn't then it is indeed obfuscated. But a similar model is heavily used
by the network stack with cpu_rmap, where this was derived from.

But regardless, its been two years, it is effectively dead code, and not
a single user complained about missing it. So we can safely purge them
and if someone cares about it, we can debate adding it back.