[openib-general] gen2 dev branch

[Yaron Haviv]

On Sunday, August 01, 2004 4:47 AM, Roland Dreier wrote:
>     Yaron> I don't see where is the policy vs mechanism, we suggest a
>     Yaron> mechanism that works and performs in the most extreme cases
>     Yaron> possible , enable more functionality, more scalable, and
>     Yaron> easier to work with, and the only counter arguments I see
>     Yaron> is that the MAD snooping is not flexible
> 
>     Yaron> I still think you don't have a real reason to object to our
>     Yaron> model so aggressively, most people in this list support it,
>     Yaron> it can work with your code, and we are quite open to
>     Yaron> incorporate any useful suggestions as long as they are
>     Yaron> focused and productive.
> 
> I don't like the assumption that there is only one consumer
> for each MAD. 

Any reason we should have more than one consumer for the same MAD beside
snoop ?
Should that be the main guideline when we build a GSI layer ?

> I don't like building a general kernel GSI
> layer when the SA client is the only known consumer. 

Just from what people use today: CM, SA, PM, DM, and vendor specific (we
use for SM sync) GSI consumers
So do we want to repeat the same GSI functionality for each of them ?

In our case a client sends a MAD, get a callback for the response, or
retry if no response arrived 
A client can be in kernel or in user, and only the relevant client will
get interrupted, so elegant :)

> I don't like to treat QP0 and QP1 so differently.      

A. QP0 and QP1 are different: different size constraints (RMPP, Direct
Route), different QP attributes and handling (Q_Key, Pkey, ..),
different variety of classes and services, different behavior in some
cases (Redirect), etc' the only common thing is that they use MAD's

B. I also don't see any reason for QP0 MAD's to be handled by few
consumers on the same time
you need at the most to register based on hca, port, mngr/agent (you
even suggested having the SMA as part of the driver) 
 
> However I agree that you approach can be made to work for today's
> applications, so if Sean is comfortable with it I will go along.  In
> any case we can always replace it later if it turns out I'm right.  
> 
>  - Roland

Give other people some credit, it wont hurt :) 
if there will be bugs/limitations we will fix them, I don't see any
reason to totally replace it in future, its already a proven solution. 

Yaron