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? -- 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
