[openib-general] [RFC] determining which changes in svn to merge upstream or remove

[Michael S. Tsirkin]

Quoting r. Sean Hefty <sean.hefty at intel.com>:
> Subject: [RFC] determining which changes in svn to merge upstream or remove
> 
> Now that changes from the iWarp branch have been merged upstream, I wanted to
> get feedback about migrating existing changes in svn upstream, or removing
> features from svn.  Specifically, the following features are in svn only:
> 
> * RDMA CM:

BTW, there was a set of bugfix patches for CMA posted that didn't get acked or
nacked yet.  They looked sane and I took them into ofed - could you take the
time to review please? Should I repost?  It might make sense to put stability
fixes in before adding more features.

>         - userspace support

I think we agreed that this will use timewait support in
core/low level drivers to handle timewait/stale packets right.
Is that right? If so, I really need to fid the time to do this.

>         - multicast support
>         - UD QP support (required for multicast)
>         - IB specific options (set paths, CM timeouts)

I think that at some point we agreed that at least the option to set
retry count can be made generic (with a limit of 15 retries).
This kind of makes sense since TCP sockets have SYN retry option.

Wrt CM timeouts, asking the ULP to guess the timeout
does not make much sense to me - how does the ULP know?
IMO we need to implement a smarter heuristic that will set them
automatically somehow. Is RDMA CM using all data from the path record
query already? How about implementing exponential backoff? Other ideas?

> * Local SA cache

This is supposed to reduce the load on SM, but personally, I am still not
convinced this is actually necessary - we are seeing gen2 based clusters running
just fine without these tricks.

What is more, this seems to break the model of IB network as a centrally managed
fabric, and a look at the code gives me the feeling no one thought through how
this will interact with SM features such as QoS, balancing, tavor MTU
optimizations etc.

> * IB multicast module

Last time I tested this, there still were crashes with the IPoIB.
If there's a patch that adds just this change, I might be able to test it.
OTOH, I'm still not sure why are we touching IPoIB at all since
it seems unlikely any other ULP will want to share in the IPoIB mcast group.


-- 
MST