airoha_eth: PPE flow entries and EGRESS TRTCM shaping
From: Wayen Yan
Date: Fri Jun 19 2026 - 07:32:39 EST
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