PPE flowtable offload on ipq807x (was: packet steering and bidirectional forwarding on ipq807x)

[John Macias]

Hello Julius,

Following up on the steering thread: with forwarding clean at 1 Gb/s,
CPU0 (all RX) and CPU1 (TX completion) were still 92-95% and 55-97%
busy, and software flow offload did not touch them. So I tried the
PPE's L3 flow tables, and they work on this v1 silicon. As Robert asked
for OpenWrt patches to go through GitHub, the patch is a draft pull
request:

  https://github.com/openwrt/openwrt/pull/26176

I know v1 is an edge case for you, so the patch stays out of the way:
nothing changes until a flowtable with "flags offload" binds, and
unbinding puts the L3 tables back.

Results on the RAX120 v1, iperf3 from a LAN client to a WAN host
through NAT. CPU busy is CPU0/1/2/3 in percent, first with software
forwarding, then with the patch:

- UDP 900+900 Mb/s: 0.00% loss.
  CPU 92/56/40/47 before, 1/3/2/1 after.
- TCP both ways: 939+936 Mb/s (928+788 before).
  CPU 92/93/50/57 before, 1/4/4/3 after.
- 600 s with 16 TCP connections both ways: 928+936 Mb/s, CPU idle.

The pull request has the rest of the results, and what I measured
about the tables that qca-ssdk does not document. Questions, if you
have time:

1. Is the EDMA hook acceptable? ndo_setup_tc only forwards TC_SETUP_FT
   to ds->ops->port_setup_tc on the CPU port, so neither driver calls
   the other directly.
2. Each user port gets the L3 interface of its own index through
   L3_VP_PORT_TBL. The port mapping alone was enough here, so I left
   your VSI allocation alone. Would you rather tie it to the VSIs?
3. Would you want this as a separate patch, or folded into the driver
   series?

Only tested on RAX120 v1 (IPQ8074 rev 1.2), not on later IPQ8074
revisions or IPQ6018.

This was written with an AI coding assistant (Claude, from Anthropic).
It worked out the table semantics on my hardware, wrote the driver
changes and this message, and ran the tests. I have reviewed the patch.

John