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

Or Gerlitz
2018-01-05T15:22:14Z

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?