Re: [PATCH rdma-next v2 00/14] index e382a3ca759e..d4a471a76d82 100644

Daniel Jurgens
2018-01-05T15:57:26Z

On 1/5/2018 9:22 AM, Or Gerlitz wrote:
> On Fri, Jan 5, 2018 at 5:03 PM, Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
>> On 1/5/2018 8:59 AM, Or Gerlitz wrote:
>>>> Operating this way isn't ideal though. In DPR mode the FW biases the schedule queue
>>>> allocation to the master port. Performance could be worse on the VFs that could be slave
>>>> ports if they are used as normal IB devices.
>>> So the FW doesn't have any indication that these driver instances are
>>> unware to what's going
>>> on? doesn't sounds ideal as you said and as life are. It's uneasy to
>>> come up with designs
>>> that would let the different Unmodified/Modified PF/VF combinations
>>> (U/M M/U) work @ their
>>> best, but we should aim there, this time it sounds that didn't work
>>> and we will have to live with
>>> that unless you can think on a way to get the FW signal that to
>>> themselves and avoid the bias.
>> The schedule queue allocation happens during FW boot, even before the PF drivers are loaded.
>> I don't think there's any way around it in this case.
> You mentioned PF drivers.. in multi-host config we can run into the
> same U/M M/U problem.
> some hosts/PF instances run the modified code and while other
> hosts/PFs unmodified code,
> or in this case the U PFs will not enable the feature? and if this is
> the case, the FW does know
> how to handle U PFs and their VFs?

Unmodified driver on one side fo the multihost or even a non-multihost configuration with unmodified drivers with a card with this feature enabled would be the same as the VM scenario.  Single one port IB device per function, with the unbalanced allocation of schedule queues in FW.