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