On Wed, May 25, 2011 at 11:24 PM, Or Gerlitz <[email protected]> wrote: > Roland Dreier wrote: >> >> I mean set the MTU port-by-port with the module loaded, the same way >> we are supposed to be able to do for the port type. Rather than having >> one global module parameter. > > The HCA has set of per port buffers, from which comes the dependency between > VLs to MTU. So with this code running for each IB hca/port, we're actually > doing that logic port-by-port. I assume you didn't mean let the user specify > a desired MTU for each hca/port... or I'm still not fully with you? > > Anyway, I'd be happy to provide at least the folks that use torus/mesh > and/or sophisticated QoS schemes an ability to use eight VLs with the > current HW, so how about keeping the module param but with default value > turned on?
What I'm trying to say is that a global module parameter is a pain for users. Would it make sense to have a "port_type" module parameter where you could set all the ports to IB or to ethernet, and have no way to have a mix of port types or change without reloading the module? The obvious answer is no, and therefore we have mlx4_portX attributes in sysfs that are per port. MTU is the same way. For example, you suggest that CX3 won't have the same limitation of only 4 VLs with 4K MTU. In that case, think about a system with one CX2 and one CX3 -- should the CX3 be limited to 2K MTU because of CX2 limitations? Rather than having a completely different way of handling MTU, why can't we just handle it the same way as the port type, and have a sysfs attribute like "mlx4_mtuN" for each port? - R. -- 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
