<html><body>
<p><tt>openib-general-bounces@openib.org wrote on 05/09/2006 04:35:57 PM:<br>
<br>
> > Heiko> Yes, I agree. It would not be an optimal solution, because<br>
> > Heiko> other upper level protocols (e.g. SDP, SRP, etc.) or<br>
> > Heiko> userspace verbs would not be affected by this<br>
> > Heiko> changes. Nevertheless, how can an improved "scaling" or<br>
> > Heiko> "SMP" version of IPoIB look like. How could it be<br>
> > Heiko> implemented?<br>
> ><br>
> > The trivial way to do it would be to use the same idea as the current<br>
> > ehca driver: just create a thread for receive CQ events and a thread<br>
> > for send CQ events, and defer CQ polling into those two threads.<br>
> ><br>
> > Something even better may be possible by specializing to IPoIB of <br>
> > course.<br>
> <br>
> The hardware IRQ should go to some CPU close to the hardware itself. <br>
> The<br>
> softirq (or whatever else) should go to the same CPU that is handling <br>
> the<br>
> user-level task for that message. Or a CPU close to it, at least.<br>
> </tt><br>
<tt>I believe softirqs have a strong CPU affinity and will execute on the same CPU that</tt><br>
<tt>handled the hard irq.</tt><br>
<br>
<tt>Pradeep</tt><br>
<tt>pradeep@us.ibm.com<br>
> <br>
> Segher<br>
> <br>
> _______________________________________________<br>
> openib-general mailing list<br>
> openib-general@openib.org<br>
> <a href="http://openib.org/mailman/listinfo/openib-general">http://openib.org/mailman/listinfo/openib-general</a><br>
> <br>
> To unsubscribe, please visit <a href="http://openib.org/mailman/listinfo/openib-general">http://openib.org/mailman/listinfo/openib-general</a><br>
</tt></body></html>