From: "Zhou, Yun" <yun.zhou@windriver.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: marcin.s.wojtas@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, maxime.chevallier@bootlin.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] net: mvneta: re-enable percpu interrupt on resume
Date: Fri, 19 Jun 2026 09:15:05 +0800 [thread overview]
Message-ID: <52e2dc9b-45ce-4779-8ca3-b4e022380db6@windriver.com> (raw)
In-Reply-To: <20260618155337._cxJpvd0@linutronix.de>
On 6/18/2026 11:53 PM, Sebastian Andrzej Siewior wrote:
> On 2026-06-18 23:45:51 [+0800], Zhou, Yun wrote:
>>> Having a NAPI instance with IRQ per queue and those configured and
>>> spread among CPUs should cause less trouble and is what others do.
>>> In fact is the only net driver using per-CPU interrupts.
>>>
>> It is a SoC limitation. Armada XP's MPIC provides a single shared
>> interrupt for the ethernet controller with per-CPU masking for
>> interrupt steering — there are no per-queue MSI vectors. The percpu
>> IRQ model was the only way to distribute interrupt handling across
>> CPUs given this hardware constraint.
>
> Is this a hardware constraint or more a software design choice? From the
> other comment it read like it could be changed.
> There is nothing wrong to provide 4 interrupts for a device from the
> device-tree and then allocate and request all four. This requires that
> SMP affinity is supported properly in order to spread it across CPU. You
> would also be able to reduce the amount of queues/ interrupts via
> ethtool if you would like to isolate a CPU for NOHZ reasons.
>
This is a hardware constraint, not a software design choice.
On MPIC platforms (armada-370/XP/38x), the mvneta interrupt (e.g.
hwirq 8) is a per-CPU hardware interrupt line (hwirq < 29 in MPIC).
It is a single physical interrupt source that MPIC routes to all CPUs
simultaneously — each CPU has its own per-CPU mask register to
independently control whether it responds to that same line.
There are not 4 separate hardware interrupt lines that could be
individually allocated. The irqchip driver (irq-armada-370-xp.c)
marks these hwirqs as IRQ_PER_CPU_DEVID in mpic_irq_map():
if (mpic_is_percpu_irq(hwirq)) {
irq_set_percpu_devid(virq);
irq_set_chip_and_handler(virq, &mpic_irq_chip,
handle_percpu_devid_irq);
}
This means request_percpu_irq() is the only valid registration
method — a plain request_irq() would fail with -EINVAL because the
irq descriptor requires IRQ_PER_CPU_DEVID semantics.
The multi-interrupt approach (like MSI-X NICs) would require the
hardware to provide multiple distinct interrupt lines per port,
which this SoC does not have.
BR,
Yun
prev parent reply other threads:[~2026-06-19 1:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-18 10:43 [PATCH v3] net: mvneta: re-enable percpu interrupt on resume Yun Zhou
2026-06-18 12:51 ` Sebastian Andrzej Siewior
2026-06-18 13:56 ` Zhou, Yun
2026-06-18 15:04 ` Sebastian Andrzej Siewior
2026-06-18 15:34 ` Maxime Chevallier
2026-06-18 15:45 ` Zhou, Yun
2026-06-18 15:53 ` Sebastian Andrzej Siewior
2026-06-19 1:15 ` Zhou, Yun [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52e2dc9b-45ce-4779-8ca3-b4e022380db6@windriver.com \
--to=yun.zhou@windriver.com \
--cc=andrew+netdev@lunn.ch \
--cc=bigeasy@linutronix.de \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcin.s.wojtas@gmail.com \
--cc=maxime.chevallier@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox