On 1/5/2018 9:22 AM, Or Gerlitz wrote: > On Fri, Jan 5, 2018 at 5:03 PM, Daniel Jurgens <danielj@xxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
