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

[Pradeep Satyanarayana]

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)?

Pradeep