Heiko> Yes, I agree. It would not be an optimal solution, because
Heiko> other upper level protocols (e.g. SDP, SRP, etc.) or
Heiko> userspace verbs would not be affected by this
Heiko> changes. Nevertheless, how can an improved "scaling" or
Heiko> "SMP" version of IPoIB look like. How could it be
Heiko> implemented?
The trivial way to do it would be to use the same idea as the current
ehca driver: just create a thread for receive CQ events and a thread
for send CQ events, and defer CQ polling into those two threads.
Something even better may be possible by specializing to IPoIB of
course.
The hardware IRQ should go to some CPU close to the hardware itself.
The
softirq (or whatever else) should go to the same CPU that is handling
the
user-level task for that message. Or a CPU close to it, at least.
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
