Roland Dreier <[email protected]> wrote: > And 4K MTU should probably be the default, since almost all users > want 4K MTU vs. caring about VLs. (Probably 99% of IB users > never set SL of anything)
I agree that we want that to be the default, I'm not sure the 99% thing is accurate, with more and more (specifically the huge ones) IB clusters that are built in some sort of 2D/3D torus, mesh or alike topologies for which routing engines such as DOR and LASH use multiple VLs to avoid credit loops. also I assume that some users (maybe < 5%) would like to enjoy 8 HW traffic classes, so if pressed to the wall, they would prefer 2k mtu with the current HW. > I mean is there anyone who really uses >4 VLs? Presumably the > HW designers didn't think so, because they limited HW to 4 VLs with 4K MTU. I'm not sure if 4 VLs are enough for all the topologies / algorithms I mentioned above, so I do prefer to leave an option to run with eight VLs. As for the HW designers comment, its always good to look forward for improvements in newer HCA drops (the patch for the CX3 series device IDs is already comitted by 31dd272e8cbb32ef31a411492cc642c363bb54b9, so one can expect for the actual cards to be coming soon as well). > At least can we make this a runtime thing? If we're able to set a > port as IB vs ethernet then # of VLs seems like it should be doable too. Here I lost you again, the policy is dictated by the module param, which whose default value should be turned on, the code that sets the mtu and VL cap is executed each time the function change by the patch is called, which in turn happens each time an IB link type is sensed or dictated for the port. Or. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
