Yeah unfortunately I won't get much time to look at it until Thursday / Friday
But I'm happy to trawl through more of the QCA commit then 
quarky
2508
From what I can remember, nss-clients should not be required for PPPoE acceleration.
@robimarko / @dchard
Compile tested only, added the bare minimum kernel patches for nss-drv-pppoe (enable package qca-nss-drv-pppoe)
@quarky from what i can tell on QSDK 11.3 without the following ecm / nss-drv have no idea what pppoe iface / channels its seeing traffic from / to
https://source.codeaurora.org/quic/qsdk/oss/lklm/nss-clients/tree/pppoe/nss_connmgr_pppoe.c?h=NHSS.QSDK.11.3#n257
2 Likes
quarky
2510
It’s been a while since I last tried tho. So I could have remembered wrong. Pls try it out.
Yeah will give it a run tomorrow after work, unless someone else like @dchard tests that branch 1st
I don't think it will fully work, maybe get closer.
It would be nice to have PPPoE and NAT offloading on these devices, ath11k seems pretty well optimized so should be happy running on the main CPU.
4 Likes
dchard
2512
Just built it, PPPoE works, but no acceleration, stats are all 0.
However, I can't see the "qca-nss-pppoe.ko" module loaded, or actually present on the router.
MOD: my bad, old build not cleaned properly.
Now the PPPoE module loads.
Interesting finding: by default (with dev.nss.pppoe.br_accel_mode = 1) PPPoE session is not set up, and the NSS PPPoE counters are all 0.
But, if I set the dev.nss.pppoe.br_accel_mode = 0, then PPPoE comes online, the NSS PPPoE stats looks fine, and.... acceleration seems to work At 950Mbits DL the CPU load is 1-2%.
root@XAX6:~# cat /sys/kernel/debug/qca-nss-drv/stats/pppoe
#pppoe base node stats start
pppoe_rx_packets = 1435877 common
pppoe_rx_bytes = 1887462868 common
pppoe_tx_packets = 827130 common
pppoe_tx_bytes = 651432477 common
pppoe_rx_dropped[0] = 0 drop
pppoe_rx_dropped[1] = 0 drop
pppoe_rx_dropped[2] = 0 drop
pppoe_rx_dropped[3] = 0 drop
pppoe_short_pppoe_hdr_length = 0 exception
pppoe_short_packet_length = 0 exception
pppoe_wrong_version_or_type = 0 exception
pppoe_wrong_code = 0 exception
pppoe_unsupported_ppp_protocol = 0 exception
pppoe_disabled_bridge_packet = 0 exception
- nss interface id=28, netdevice=pppoe-digi
#pppoe session node stats
pppoe[0]_rx_pkts = 1435854 common
pppoe[0]_rx_byts = 1875950260 common
pppoe[0]_tx_pkts = 827126 common
pppoe[0]_tx_byts = 651429405 common
pppoe[0]_wrong_version_or_type = 0 exception
pppoe[0]_wrong_code = 0 exception
pppoe[0]_unsupported_ppp_protocol = 6 exception
3 Likes
dchard
2514
Just found that the "dev.nss.pppoe.br_accel_mode" parameter controls pppoe bridge acceleration in NSS. So it seems when it is enabled, PPPoE acceleration does not work.
PPPoE bridge acceleration
Maybe there is still work needs to be done on the bridge acceleration, or this value should be 0 by default in our case?
Yeah that's odd but it does look to be offloading ok when it's set to 0 ? I'll check how that flag is used later today
dchard
2516
Yes, it seems to work fine.
just got an AX3600 from my neighbor and want to give it a shot with this (https://github.com/BuzzBumbleBee/openwrt/tree/AX3600-5.10-QSDK11.3-PPPOE-TEST) build. SSH is set up and the build is ready.
What are the actual steps to install it now?
scp the openwrt-ipq807x-generic-xiaomi_ax3600-squashfs-nand-factory.ubi and sysupgrade, or is there anything else necessary before I can install it?
Or do I first need to do the ubidetach and ubiformat?
ubidetach -f -p /dev/mtd13
ubiformat /dev/mtd13 -y -f /tmp/openwrt-ipq807x-generic-xiaomi_ax3600-squashfs-nand-factory.ubi
after that reboot and sysupgrade with the openwrt-ipq807x-generic-xiaomi_ax3600-squashfs-nand-sysupgrade.bin?
@Apache14 Like @dchard said it controls the PPoE bridge offloading for cases where the PPoE interface is attached to a bridge.
dev.nss.pppoe.br_accel_mode:
0 is disabled,
1 is 5 tuple,
2 is 3 tuple mode.
This is handled in the NSS-DRV by the nss_ppoe.
So, its a bit weird that it does not work, but I would argue that its not that important.
Would you mind if I picked your patches to my branch?
Feel free, I tried to raise an MR but GitHub wouldn't let me
Hm, PR-s can be my against my OpenWrt fork, I had people do that in the past.
If you have it as a remote Github will most likely even offer that.
Ohh yeah we may need to add bridging patches to get other modes working
But is it worth it to support PPoE bridging?
I am afraid that we will end up with a ton of NSS related patches.
@Ansuel I see that your SMEM patch to stop it from leaking memory already has 2 reviews, nice job.
Anyway, I see that Felix pushed the hostapd changes so I rebased onto those.
Disabled the accidentally enabled IOMMU support in the kernel as well.
3 Likes
I don't think I'll put much effort into those, form my point of view NAT / minimal changes for PPPoE offloading should be enough
The main core is powerful enough to have other things like VPN and ath11k seems pretty well optimized
I aggree, NAT and PPoE offloading should cover like 90% of the use cases.
ath11k should not be a resource hog as it just interfaces with the kernel, it does not do anything special.
All of the hard stuff is in the FW, kernel only has to deal with the IRQ-s.
I am messing with the SPMI VADC to provide those 4 thermistors its has.
Weirldy, QCA patch applies directly but as always they instantly do everything in one patch.
They even left the debug prints with raw ADC values by default.
dchard
2525
You mentioned that the regdb is encoded in the firmware. What if I take the original firmware from the device and load that? As much as I know, it had the correct regdb as channel 13 definitely worked.
