Netdev List
 help / color / mirror / Atom feed
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