From: Wayen Yan <win847@gmail.com>
To: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: airoha_eth: PPE flow entries and EGRESS TRTCM shaping
Date: Fri, 19 Jun 2026 19:32:16 +0800 [thread overview]
Message-ID: <178186873627.2394198.12931653355991624267@gmail.com> (raw)
Hi Lorenzo,
While reviewing the airoha HTB offload code and your recent fix series,
I noticed that EGRESS TRTCM rate-limit buckets configured by
airoha_qdma_set_tx_rate_limit() do not appear to be referenced by
either the CPU xmit path or PPE-accelerated flows.
Specifically:
1) CPU xmit path always disables the meter:
In airoha_dev_xmit(), TXMSG.METER is hardcoded to 0x7f:
msg1 = FIELD_PREP(QDMA_ETH_TXMSG_METER_MASK, 0x7f);
The register comment notes "0x7f no meters", so even though
airoha_tc_htb_alloc_leaf_queue() configures TRTCM bucket[channel]
with the requested rate, CPU-path packets never hit those buckets.
2) PPE flow entries never bind to a TRTCM bucket:
In airoha_ppe_foe_entry_prepare(), the FOE 'data' field is
initialized with:
qdata = FIELD_PREP(AIROHA_FOE_SHAPER_ID, 0x7f);
And neither CHANNEL[15:11] nor QID[10:8] are ever set — they
remain zero in all PPE entry creation paths (tc offload,
HW autolearn, L2 subflow commit). This means PPE-accelerated
flows bypass TRTCM shaping entirely.
The only QoS-related bit set is IB2.PSE_QOS for wired LAN ports,
which is a flag rather than an index.
3) airoha_ppe_foe_flow_stats_update() does read CHANNEL|QID from
the data field and moves them to ACTDP, but since they were
never populated, this is effectively a no-op in practice.
I have a few questions:
- Does AIROHA_FOE_SHAPER_ID map to the same QDMA TRTCM meter index
space used by airoha_qdma_set_tx_rate_limit()? If so, setting
SHAPER_ID = channel for flows belonging to an HTB class would
enable per-flow egress shaping via PPE.
- Is the current 0x7f / disabled behavior intentional — i.e., PPE
flow shaping is simply not yet implemented, or is there a hardware
constraint I'm missing?
- For the CPU xmit path, is there a reason TXMSG.METER cannot be
set to the channel derived from skb_get_queue_mapping(), so that
CPU-path packets also respect the TRTCM rate limits?
Thanks,
Wayen
reply other threads:[~2026-06-19 11:32 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=178186873627.2394198.12931653355991624267@gmail.com \
--to=win847@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=netdev@vger.kernel.org \
/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