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