[BPI-R4] any plans for jumbo frame support?

Banana Pi Router design BPI-R4/BPI-R4 Pro(MT7988)
83

i wonder why you have with rss alone only 4.5 GBit/s…do you do bidir iperf-check? i had around 7.2GBit/s with RSS, but there was an iperf3 issue too where i had to use iperf2…not sure if it was RSS or LRO

btw. RSS/LRO is currently reworked by mtk due to the report from user mescheen (LRO does only catch a small amount of packets)

i’m not sure the corruption is caused by LRO or the mainline-code…but yes, there are patches for it from mescheen in my latest branches

84

i wonder why you have with rss alone only 4.5 GBit/s…[…] i had around 7.2GBit/s with RSS, but there was an iperf3 issue too where i had to use iperf2…not sure if it was RSS or LRO

unsure, did one more test, it’s not the threaded = 1 vs threaded = 0 difference openwrt/bpi-r4pro-8x/notes/rss-multiring-napi-experiment.md at 75274359908e7f49fbfab390d5baa36fab3fefcc · Lauri-Nomme/openwrt · GitHub

test	threaded=1 (r195)	threaded=0 (r201)
MTU1500 ingress P1	5.25 G	5.30 G
MTU1500 ingress P4	6.66 G	5.27 G (2822 retr)
MTU1500 ingress P8	6.33 G	4.86 G (4098 retr)
MTU1500 egress P1	9.37 G	9.37 G
MTU1500 egress P4	9.35 G	9.40 G
MTU9000 ingress P4	9.88 G	9.16 G (350 retr)
MTU9000 egress P4	9.91 G	9.90 G

do you do bidir iperf-check?

i measure single-dir

85

Could you try with iperf(2)?

86

A useful way to separate the kernel limitation from the switch path is to test each interface independently: set the same MTU on both endpoints first, then on one LAN port at a time with ip link set dev <iface> mtu 9000, and verify with ip -d link plus a DF ping sized below the MTU. If the host interface accepts 9000 but a DSA LAN port returns ERANGE, that points to the switch/DSA driver path rather than cabling. It would also be worth recording whether the behavior differs between copper LAN and SFP, since that can narrow down where the MTU is being constrained.

87

A useful way to separate the kernel limitation from the switch path […] narrow down where the MTU is being constrained.

while 100% correct generally, in this specific case, the MTU was being constrained by missing support in the upstream mtk driver, which has been improved by porting downstream mtk & frank-ws changes

88

Could you try with iperf(2)?

iperf2 TCP, 10 s, both directions:

direction	    9000 P4	9000 P1	1500 P4	1500 P1
cw → banana	        9.81	9.69	6.24	4.75
banana → cw	        8.98	9.83	8.50	9.38
cw → odroid	        2.47	2.46	2.35	2.35
odroid → cw	        2.47	2.47	2.35	2.35
banana → odroid 	2.47	2.47	2.35	2.35
odroid → banana 	2.47	2.47	2.35	2.35

Findings:

  • odroid is the 2.5 G cap: every odroid pair is ~2.35–2.47 G (odroid’s 2.5 G NIC on MxL lan2), and MTU 1500↔9000 moves it only ~5% — no CPU/RSS effect at 2.5 G.
  • banana↔changwang (10 G): ~9.7–9.8 at 9000 both ways; at 1500 ingress collapses (cw→banana 6.24 P4 / 4.75 P1) while egress stays 8.5–9.4. Same asymmetric shape as iperf3.
  • iperf2 ≈ iperf3 (cw→banana @9000 P4: 9.81 vs 9.88; @1500: 6.24 vs 6.66) — so neither the 1500 ingress wall nor frank’s ~7.2 is an iperf2-vs-3 artifact.
89

You use multiple (-P4 param afair) streams? but i think we should continue this discussion in a RSS/LRO thread as this is for jumbo-frames.

e.g. this: [BPI-R4] LRO/RSS etc upstreamed?

or even a new specific to non-upstream openwrt