Sean Hefty wrote:
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.)
Sean,
Can you explain why would not the IB CM use the thread context provided
by the mad layer?
Second, if the CM needs a different context why not use the system
threads? I understood from Michael's reply that the CM code relies on
some thread/queue flushing at the time of CM ID destruction, is it an
implementation issue that can change? if not, can't one dedicated thread
do the job?
Or.
_______________________________________________
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
