[openib-general] gen2 dev branch

[Yaron Haviv]

On Saturday, July 31, 2004 8:10 PM, Roland Dreier wrote:
>     Roland> (in fact that is how the Topspin stack works and what I
>     Roland> would expect we would want to do).
> 
>     Yaron> I sense that's your main reason for resistance, it is not a
>     Yaron> valid claim, the essence of Matt's proposal is that no ones
>     Yaron> stack is more important than the other, you agreed in the
>     Yaron> pass that SA/GSI is not your strong part so we should use
>     Yaron> something better
> 
> In any case you are pushing not just Voltaire's design but Voltaire's
> code as well so this is a ridiculous complaint coming from you. 

We didn't resist to tons of code pushed by Topspin, and it isn't all
that perfect or better than ours. 
The suggested gsi.h is different than our original gsi, the code is also
been drastically changed to incorporates elements suggested by you
(Slab's,..), suggested by Todd/Eitan/Sean, and remove performance and
other optimizations (so it would be more "Simple")
Those changes were made after people gave constructive feedback

The idea in Matt's proposal is that code is been contributed by few and
not just by one
Since the suggested approach can support all your needs today, I suggest
that instead of fighting it accept, 
and give some credit to others who have a fare share of experience, your
strong resistance cannot be interpreted in too many ways 
 
> What do you mean?  I've come up with several use cases and your
> response is always that you'll add yet another special case to the
> API.  

You made few remarks:
wanted dynamic memory allocation instead of pools, it was accepted, API
was changed, and code is been worked on by Hal to support it 

> For example, I suggested being able to snoop every MAD

Personally I'm ok with just having debug prints for that when people
change the verbosity level, but we did accept the requirement and added
an API for it without arguing about it

You also made a somewhat of an extreme case for needing the attribute
field, anyway its not changing the model its just adding a parameter, 
I think more filters is not better if others in this list think its not
just trying to make a case but a real requirement we will add it to the
API .

> The restriction of one consumer per
> class doesn't look right to me either -- there could be multiple
> network management applications all trying to use PM.  

There can be more than one consumer per class in our proposal, the limit
is on one server per class 
PM is a client model (issues PM requests), demux by client ID, so you
can have as many as you want and in such example it is much more
efficient to use our approach than the multi-layer, multi-filter, daisy
chain approach you suggest.
Do you see a case with few servers (accept requests) listening on the
same hca/port/class/ver/attrib ?

Did we miss or didn't address any requirement you made till now ?

> I just want to provide mechanism and not policy.
> 

I don't see where is the policy vs mechanism, we suggest a mechanism
that works and performs in the most extreme cases possible
, enable more functionality, more scalable, and easier to work with, and
the only counter arguments I see is that the MAD snooping is not
flexible 

I still think you don't have a real reason to object to our model so
aggressively, most people in this list support it, it can work with your
code, and we are quite open to incorporate any useful suggestions as
long as they are focused and productive. 

Yaron