How can we make the lantiq xrx200 devices faster

When testing the DSA driver on the BT HH5A did you see any CPU going as far as say 50%

Only the first core(VPE) deals with the processing of packets and interrupts from the network card. The load during testing is most often less than 50%.

You can also try Threaded NAPI, but it is slower. It seems that context switching between threads (VPE) costs a lot.

Will these changes be part of the 21.02 release?

No, it's way too late for that - there'll always be a next release.

http://lists.openwrt.org/pipermail/openwrt-devel/2021-June/035711.html

Fingers crossed

Some IPv6 Routing benchmark (LAN<->WAN) on the BT HH5A with enabled software offloading:

Test         1W                    8W             Increase
WAN->LAN   330 Mb/s              490 Mb/s           +48 %
LAN->WAN   338 Mb/s              590 Mb/s           +75 %

Burst length PR.

4 Likes

@olek210

This works for me except where a 100M wired device is connected to the bthh5a switch, the router issues an ip but the linux laptop never connects. Works fine with 1G wired etherne, wifi, usb WWAN etc. I cannot test xDSL.

Thank you for your excellent work on speeding up the xrx200!

EDIT: My bad, a new ethernet cable sorted out the 100M wired link! Superb work. Thank you. I am building with kernel 5.10.46.

Hi Aleksander,

I get wan using a huawei modem that presents as an NCM device. Applying your patches resulted in my LAN --> WAN speed doubling!!!

I greatly appreciate your excellent contribution! Thank you very much.

Mine setup is also BTHH5a with kernel 5.10.46.

Hi,
@PaulRowland @DermotMcDonnell and everyone interested in this PR
Thanks for the tests. It would be great if you could add it in the form of a
Tested-by: your name <your@email> # tested on device/model.

Best regards,
Aleksander

Hi Aleksander,

I am new to testing pull requests. Should I set up an account on github and comment on your pull request there?

Thanks again!!

I did git pull this morning and built with your latest patches, flashed it and now lan ports 1->4 do not connect. The Red WAN port on the bthh5a works fine. This is what I see in syslog:

Mon Jul 12 11:55:35 2021 kern.info kernel: [   95.408869] br-lan: port 4(lan4) entered disabled state
Mon Jul 12 11:55:35 2021 daemon.notice netifd: Network device 'lan4' link is down
Mon Jul 12 11:55:39 2021 kern.info kernel: [   98.525424] gswip 1e108000.switch lan4: Link is Up - 10Mbps/Half - flow control off
Mon Jul 12 11:55:39 2021 kern.info kernel: [   98.531716] br-lan: port 4(lan4) entered blocking state
Mon Jul 12 11:55:39 2021 kern.info kernel: [   98.537244] br-lan: port 4(lan4) entered forwarding state
Mon Jul 12 11:55:39 2021 daemon.notice netifd: Network device 'lan4' link is up
Mon Jul 12 11:56:29 2021 daemon.info dnsmasq-dhcp[4211]: DHCPREQUEST(br-lan) 192.168.1.237 xx:xx:xx:xx:xx:xx
Mon Jul 12 11:56:29 2021 daemon.info dnsmasq-dhcp[4211]: DHCPACK(br-lan) 192.168.1.237 xx:xx:xx:xx:xx:xx pr-pc
Mon Jul 12 11:56:31 2021 daemon.info dnsmasq-dhcp[4211]: DHCPDISCOVER(br-lan) 192.168.1.237 xx:xx:xx:xx:xx:xx
Mon Jul 12 11:56:31 2021 daemon.info dnsmasq-dhcp[4211]: DHCPOFFER(br-lan) 192.168.1.237 xx:xx:xx:xx:xx:xx
Mon Jul 12 11:56:33 2021 daemon.info dnsmasq-dhcp[4211]: DHCPDISCOVER(br-lan) 192.168.1.237 xx:xx:xx:xx:xx:xx
Mon Jul 12 11:56:33 2021 daemon.info dnsmasq-dhcp[4211]: DHCPOFFER(br-lan) 192.168.1.237 xx:xx:xx:xx:xx:xx
Mon Jul 12 11:56:38 2021 daemon.info dnsmasq-dhcp[4211]: DHCPDISCOVER(br-lan) 192.168.1.237 xx:xx:xx:xx:xx:xx
Mon Jul 12 11:56:38 2021 daemon.info dnsmasq-dhcp[4211]: DHCPOFFER(br-lan) 192.168.1.237 xx:xx:xx:xx:xx:xx
Mon Jul 12 11:56:47 2021 daemon.info dnsmasq-dhcp[4211]: DHCPDISCOVER(br-lan) 192.168.1.237 xx:xx:xx:xx:xx:xx
Mon Jul 12 11:56:47 2021 daemon.info dnsmasq-dhcp[4211]: DHCPOFFER(br-lan) 192.168.1.237 xx:xx:xx:xx:xx:xx
Mon Jul 12 11:57:03 2021 daemon.info dnsmasq-dhcp[4211]: DHCPDISCOVER(br-lan) 192.168.1.237 xx:xx:xx:xx:xx:xx
Mon Jul 12 11:57:03 2021 daemon.info dnsmasq-dhcp[4211]: DHCPOFFER(br-lan) 192.168.1.237 xx:xx:xx:xx:xx:xx

I tried 100M and 1G devices also, same result in syslog.

Is this the ethernet HW acceleration driver source code for Lantiq?

After trying those lines I have discovered they are included in /etc/hotplug.d/net/20-smp-packet-steering. (OpenWrt 21.02)

Strange thing is TX cpus can't be modified, i.e.:

/sys/class/net/wlan0/queues/tx-0/xps_cpus
/sys/class/net/wlan1/queues/tx-0/xps_cpus

Does anybody know how can TX be tweaked?

Thank you.

I have good results using FB7412 and Open master 5.4 with pull 4353 and 4339 and with VPE-IRQ patch
Just three clicks to include them in OpenWrt master branch to benefit all

1 Like

now that there has been more of a push towards the kernel 5.10 and the DSA driver instead of the legacy driver it appers that there's been a fair amount of work to bring the things pc2005 worked on into the new driver

Extra stuff appears to be in this developer's branch : https://github.com/abajk/openwrt/commits/lantiq-jumbo-test

Like:

However I am unable to get the ethernet ports working on my BT home hub 5a after merging this branch. Can anyone with serial access (so they don't brick their router unless they have a pre-existing config set to bridge a usb ethernet adapter onto br-lan) confirm that ? (kernel 5.10). The ports acknowlege there is a link is up but no ping or other access for me.

Hi @wilsonyan,
I am the original author of these patches. This is an older patch version and it is broken. Here is a newer version of the patch. This patch probably doesn't improve performance. You will find more patches in my repository. Some are untested.

Combining 4 patches increases performance by 25%:

I will send patches upstream on the next net-next cycle.

1 Like

I also saw you have a patch to use 4 TX queues, was any testing done on that one? I'm seeing a frequent 'tx ring buffer full' error that sometimes stalls the ethernet connection. Any idea if this patch could help to resolve that? Thanks!

The patch for TX queue 4 has not been tested. 'Tx ring buffer full' messages appear on the console because DMA is slow. The system fills the descriptors faster than dma releases them. I think patches from this PR should solve this problem.

Using all the patches I was able to achieve 725 Mb / s upload and around 600 Mb / s download speed.

3 Likes

impressive. So in this case the 4 patches you mentioned in your earlier post? If I understand correctly then most of them were sent upstream and it might take some time until they are pulled in openwrt?