[openib-general] gen2 dev branch

[Yaron Haviv]

On Friday, July 30, 2004 1:52 AM, Roland Dreier wrote:
>     Yaron> Roland approach is to have a chain of filters
>     Yaron> (hca/port/qpn/class/method/attrib/dir/mask/name) that
>     Yaron> forwards the MAD to multiple consumers based on the filter
>     Yaron> list, the consumer must copy the MAD, if for e.g. there are
>     Yaron> multiple SA clients than each one will get the MAD and will
>     Yaron> need to decide if its his MAD (I assume that's also the
>     Yaron> reason attrib is needed in such approach, not because of
>     Yaron> futuristic SM)
> 
> I guess I should have been clearer in my description.  Nothing forces
> the consumer to copy the MAD unless it wants to keep the MAD around
> for later.  Also nothing prevents us from implementing an SA layer on
> top of the basic MAD layer that handles demultiplexing multiple
> consumers, etc. 

I don't see how having two layers of demux+filters for SA and a daisy
chain of code more "simple" than just issue the callback based on the
TID (client ID), the SA query part can be as little as a MAD template on
the send and retry if no response arrives 

>(in fact that is how the Topspin stack works and what
> I would expect we would want to do).     

I sense that's your main reason for resistance, it is not a valid claim,
the essence of Matt's proposal is that no ones stack is more important
than the other, you agreed in the pass that SA/GSI is not your strong
part so we should use something better  

> I'm not too concerned about the details of what I proposed; I would
> just like to see a general layer that gives us the flexibility to
> experiment and deal with future requirements. 

No one of the smart guys on this list including you found even a use
case that cannot be met by our approach, if you see one please mention
it, we will address it, or don't use this argument  

> In any case I remember
> now why I gave up on this discussion the first time around.   

You gave up since we don't accept baseless claims but REAL use cases and
example, just saying your approach is "Simple" is a subjective statement
we don't agree with
 
Yaron