0

When I am implementing any network server running Linux (Intel Xeon x86_64), it is often the bottleneck becomes a single and always the same CPU-core (interrupt occurs always on the same (CPU0) core) on which arise the interruption (IRQ) of the network card that call to code of the network card driver. Is it possible to somehow achieve that the interruption arose on different processor cores (by random or round-robin), instead of single, thus balancing the load?

But: If until a hardware interrupt is not completed on a single core, it can not be caused by a different core, even if we complete the job with the network device in some way before the interrupt will finished, then:

I want that every time an interrupt occurs on different cores, then I exchange data with the network card, pile up the data that came to memory pertaining to a given CPU-core (buffer with an index of this core) and then ends the interrupt (IRQ) code. So, I want to avoid inter-thread synchronization. Each core can be performed either interrupt network card, or only one thread is bound to the cores with priority given real time. I use 1P-1C container, and all of its cache line always belongs only L1/L2 of a single core. And we need not cache synchronization (CPUx L1/L2 <-> L3 <-> CPUy L1/L2), that gives us 10x speed up.

Or better to use soft-IRQ for this instead of hardware-IRQ?

Alex
  • 12,578
  • 15
  • 99
  • 195
  • 1
    I don't think this wouldn't actually help. The interrupt needs to be handled, and it needs to be handled before the network card can do anything else. And since its an interrupt, the core will stop whatever its doing to handle it immediately. It isn't waiting around until its finished doing something else. So why do you think that would even help? – Gabe Sechan Aug 24 '13 at 09:45
  • @Gabe Sechan Yes, I know it. I corrected my question - see bold text. I don't want that interrupt call the network driver in different threads concurrently. I want that interrupt call the network driver in different thread sequentially. Or until a hardware interrupt is not completed on a single core, it can not be caused by a different core, even if we complete the job with the network device in some way before the interrupt will finished? – Alex Aug 24 '13 at 10:43

0 Answers0