Quoting r. Sean Hefty <[EMAIL PROTECTED]>: > 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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
