SNMP and Hardware Acceleration on Linksys E8450

So, I have a new issue for me. I was able to get hardware acceleration working for my gig wan connection. However, when I turned it on, all of the metrics except eth0 became severely inaccurate.

I understand it is due to the hardware filters bypassing large swaths of the networking stack. However, I am hoping there is something else I can look at to see the actual metrics. If I need to do silly scripting to get it done, I am up for it. Just need a point in the right direction for where the values exist in the hardware accelerator.

The big one is the wan connection. As this device does have the wan port as a VLAN going into eth0 I can not see any difference between wired traffic going into the switch and the wan traffic leaving the switch.

If you want accurate metrics, you can't have flow-offloading at the same time, it's an either or question. Pick your poison and choose wisely.

2 Likes

This should not be an impossible request. The data does exist, as you can see in the debug of ppe0, the streams are tracked with data-use.
/sys/kernel/debug/ppe0/entries

It also breaks the luci graphs as well.

What I have been able to get pieced together.
The traffic shows up correctly on eth0.

This is where the confusion lies.
If the hardware acceleration engine is in the CPU, why are the stats for the wan, lan1,2,3,4 ports broken? This should still be working as the switch chip should still be seeing the associated traffic.
If the hardware acceleration engine is in the switch chip, why does the main interface show traffic?

So, I found out how to read the switch directly. (ethtool -S wan)
With that I made a crude python proof of concept script

#!/usr/bin/python -u
import os
import snmp_passpersist as snmp

def update():

        pp.add_str('0.1', "wan")
        pp.add_cnt_32bit('0.2',int(os.popen("ethtool -S wan | grep RxBytes | awk '{print $2}'").read()) , "wan rx")
        pp.add_cnt_32bit('0.3',int(os.popen("ethtool -S wan | grep TxBytes | awk '{print $2}'").read()) , "wan tx")
        pp.add_str('1.1', "lan1")
        pp.add_cnt_32bit('1.2',int(os.popen("ethtool -S lan1 | grep RxBytes | awk '{print $2}'").read()) , "lan1 rx")
        pp.add_cnt_32bit('1.3',int(os.popen("ethtool -S lan1 | grep TxBytes | awk '{print $2}'").read()) , "lan1 tx")
        pp.add_str('2.1', "lan2")
        pp.add_cnt_32bit('2.2',int(os.popen("ethtool -S lan2 | grep RxBytes | awk '{print $2}'").read()) , "lan2 rx")
        pp.add_cnt_32bit('2.3',int(os.popen("ethtool -S lan2 | grep TxBytes | awk '{print $2}'").read()) , "lan2 tx")
        pp.add_str('3.1', "lan3")
        pp.add_cnt_32bit('3.2',int(os.popen("ethtool -S lan3 | grep RxBytes | awk '{print $2}'").read()) , "lan3 rx")
        pp.add_cnt_32bit('3.3',int(os.popen("ethtool -S lan3 | grep TxBytes | awk '{print $2}'").read()) , "lan3 tx")
        pp.add_str('4.1', "lan4")
        pp.add_cnt_32bit('4.2',int(os.popen("ethtool -S lan4 | grep RxBytes | awk '{print $2}'").read()) , "lan4 rx")
        pp.add_cnt_32bit('4.3',int(os.popen("ethtool -S lan4 | grep TxBytes | awk '{print $2}'").read()) , "lan4 tx")

pp=snmp.PassPersist(".1.3.6.1.3.53.8")
pp.start(update,1) # Every 30s

I then added the script to snmp

config pass
        option persist 1
        option miboid '.1.3.6.1.3.53.8'
        option prog '/usr/sbin/ethtool-switch.py'

And now the switch ports do properly isolate out traffic.

1 Like

A similar inquiry discussed here:

I was hoping to get per-flow metrics for netflow - as well as per-interface metrics, and I chased this a little bit. I found some documents describing the MT7621 register locations and such. I messed around with reading the registers with devmem, but most of the registers I'm interested in always read as zeros. I also never found anything that concretely describes the supposed per-flow metrics of the MT7621. The MT7622+ per-flow metrics code does not work for the MT7621, so either the register locations or layouts are different - alas.
I may hook my spare ER-X up to JTAG with openocd, but I'm not super-hopeful at this point that it'd help spelunking at all. This is a shame, because there are a LOT of MT7621-based devices out there, and they seem pretty grunty when HW offloading is enabled :).

One of the devs I corresponded with stated that the packets/octets that go through the hardware flows "don't go through the phy", so I assume that the realtime metrics in luci are reading those metrics.
Nice to see that there is a workaround for at least getting aggregate per-interface metrics, maybe I'll try that.

In this case I am getting the data from the built in 5 port switch using ethtool, not reading anything from the ppe. So I am limited in that aspect.
I am hoping to get something more elegant in the future, right now I am held back by a lack of expertise in python, snmp pass persistent, and getting data from siocethtool.

For my own edification I went to see where the luci metrics come from, and it turns out luci-bwc.c simply reads a couple of the files in /sys/class/net/%s/statistics/%s/<file>.
The ethtool metrics, in contrast, seem to come from the 7530 switch MIB registers through the driver in /drivers/net/dsa/mt7530.c.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.