Hi Marcin, On ven., nov. 06 2015, Marcin Wojtas <m...@semihalf.com> wrote:
> Hi Gregory, > > >> I also choose to associate all the TX queues on the same CPU that the >> one associated to the RX queue. It allows to contain all the >> interrupts on the same CPU. I think that an improvement on this side >> would be the support of the XPS. >> > > Did you make some tries? E.g. after mapping certain txqs to CPU1, when > using them was mvneta_tx() executing only on this CPU? Or it rather > means that the irq will hit according to the mapping? As far as I know > the HW, the latter should be true, which would mean the real XPS with > this controller is impossible and the maximum we can control is the > irq. I hoped that with XPS we can associate CPUs to all the tx queues of a ethernet port. For example choosing for eth2, that all the tx queues will be handled by CPU0 and CPU3. And for this it would involve allowing receiving the tx interrupts only on CPU0 and CPU3. This kind of feature seems to be doable with the hardware. But after reading more carefully what XPS is about and how it is used in the kernel, it seems we can't configure the hardware from the sysfs interface. From my understanding we can only indicate to the kernel which tx queue use for a given CPU. > > I think it may be worth to unmask TX irqs on all cpus, so all percpu > napi's would be able to read tx_cause and process sent packets. I'm > looking forward to your opinion. By doing, this my understanding is that when an TX interrupt occurs then all the CPUs enter in the interrupt handler but only one can manage it. So, for me it looks like a big waste of CPU load. I could understand that it would be interesting in some situation but it doesn't seem to be the good default behavior. That's why I was looking for a way to let the use configure it according to his needs. Please correct me if I am wrong somewhere, because currently I don't find a good solution for it. Thanks, Gregory -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
