Pradeep Satyanarayana wrote: > Sean Hefty wrote: >>> Yes, the admin could run into the problem that you describe. That is >>> exactly >>> why we have these as module parameters. It gives him/her the flexibility. >> But it doesn't give additional flexibility, and makes it more difficult. >> >> Increasing this value by itself may not do anything unless the admin >> also increase max QPs / RQ size / mtu. Similarly, increasing max QP / >> RQ size / mtu may not work without also increasing this value. Multiple >> values need to be manipulated. >> >> Decreasing this value can have the side effect of limiting max QP. This >> side effect is arbitrary. >> >> And even if this value is left unchanged, the results of changing other >> parameters is unknown. >> >> The only sure way that the admin can know what will happen is to >> understand the relationship that max QP / RQ size / mtu have on memory >> use. This parameter doesn't remove that need and makes the relationship >> between them show up in confusing ways. >> >> If admins want some way of limiting how much memory is consumed by >> ipoib, then how about creating a simple userspace app to convert their >> request into the proper kernel settings? This way, the policy is kept >> in userspace, rather than hard-coded in the kernel driver. >> > > Sean, > > As we debate this issue I do not want no srq patch to miss the 2.6.24 merge. > This has been waiting to be merged for a very long time. > > We all have a slightly different view point. This was the reason I did not > touch the module parameters in my previous patches. Can we agree to continue > discussing this, but merge the patch (I will provide the fix that you pointed > out)? >
In the interest of reaching a quick resolution, would it be acceptable if I put in a warning message (printing current memory usage) when memory usage say exceeds 1GB for no srq and also eliminate the max_receive_buffer module parameter. Is that satisfactory? Pradeep _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
