[openib-general] gen2 dev branch

[Yaron Haviv]

On Thursday, July 29, 2004 7:32 AM, Roland Dreier wrote:
> stay out of this, but I still have the feeling that we are going in a
> bad direction here, putting too much policy into an overly complex,
> inflexible API.  Rather than trying to decide in advance exactly what
> consumers should do and then adding enough flags and knobs to the API
> to implement exactly what we've decided, I think we should try and
> come up with a minimal mechanism to implement what we know we need.
> For example, we need to multiplex QP0/QP1, we want to have common
> RMPP code, etc.        

Lets review the real diff between the two approaches as I see it 

Our/Todd/Eitan approach register one server per hca/port/class/ver/flags
(and optionally attrib)
For clients the responses are directed based on the MSB of TID (client
code) 
And traps/reports can have one or more registrations

Roland approach is to have a chain of filters
(hca/port/qpn/class/method/attrib/dir/mask/name) that forwards the MAD
to multiple consumers based on the filter list, the consumer must copy
the MAD, if for e.g. there are multiple SA clients than each one will
get the MAD and will need to decide if its his MAD (I assume that's also
the reason attrib is needed in such approach, not because of futuristic
SM)

So I don't see how our demux approach is more "complex" to me it looks
simpler and more transparent, I believe Sean supported the TID based
client demux approach previously  

Since our approach is GSI MAD aware it can also perform RMPP internally
(transparently), and a client may send a MAD request to a server, when a
redirect response arrives to the GSI it automatically resend it to the
appropriate new target (without implementing it for every consumer)

Our implementation also includes some performance optimizations we are
removing now (for "Simplicity") such as Addr_Hndl caching, and mem
caching, we got the message that performance is less important than
"simplicity" in this list.

For people who need RMPP the best approach is to make it transparent
(also requested by Sean in the pass), with a simple on/off flag and not
by using libraries (that are not more simple, and require the same
amount of code)

If/when people will need Redirect support, the only reasonable place to
implement it is in the GSI layer, and not duplicate it across the code,
as I mentioned we can initially start with #if 0 the redirect code 

All in all I believe it's a better and simpler approach, that
incorporated inputs from Roland, Todd, Eitan (the open way) 

Yaron