[ofa-general] IPOB CM (NOSRQ) [PATCH V9] patch

[Sean Hefty]

> 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