It would also be possible to implement this with a symlink to the module parameter /sys/module/mdt/parameters/max_mod_rpcs_in_flight, similar to "lnet_debugfs_symlinks does for debug_mb->../../../module/libcfs/parameters/libcfs_debug_mb".
An alternate, and maybe preferable, solution would be to have "lctl get_param/set_param" look at "/sys/modules/<obd>/parameters/<param>" for parameters of the form "<obd>.<param>", which would immediately make all of the module parameters available for tuning via "lctl set_param -P".
The MDT side limit defines the maximum of the client max_mod_rpcs_in_flight. It is useful to have a max set server-side to prevent abuse by greedy clients.
Sure. My main question is whether there are technical limitations (e.g. the number of slots in the last_rcvd or reply_data is hard-coded at mount time) that prevent this parameter from being changed at mount time on the MDS and/or allow clients to have different values (e.g. if the MDS value is updated, new clients mount and get new limit, but currently-mounted clients have old limit).
An alternate, and maybe preferable, solution would be to have "lctl get_param/set_param" look at "/sys/modules/<obd>/parameters/<param>" for parameters of the form "<obd>.<param>", which would immediately make all of the module parameters available for tuning via "lctl set_param -P".
Sure. My main question is whether there are technical limitations (e.g. the number of slots in the last_rcvd or reply_data is hard-coded at mount time) that prevent this parameter from being changed at mount time on the MDS and/or allow clients to have different values (e.g. if the MDS value is updated, new clients mount and get new limit, but currently-mounted clients have old limit).