Sorry but "improve data locality" is not enough information for me to understand why the IB CM --neeed-- to spawn n kernel threads on my n-core system, after all its slow path and the data does not moves on QP1, what's the story here? and if it needs thread-per-cpu, why not use the system threads/softirqs as does the TCP/IP stack connection mgmt code?
IMO, if we're going to have multiple cores, then we should create multiple threads to use them. This becomes more important as the number of cores increases. (The overhead of a non-running thread can't be that much.) Stating that connection establishment is a slow path operation assumes that all connections are long lived.
The current behavior of the MAD layer is that all callbacks for a given registration are serialized. We either need to preserve this functionality or verify that MAD users can handle simultaneous callbacks. (Hopefully MAD users didn't make any assumptions regarding the threading model used by the MAD layer, but we need to verify this. I'm more worried about code in the MAD layer itself.)
- Sean _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
