I mean the single stream throughput your data is showing shouldn't be possible without the Marvel Fast Path driver because that is why the driver exists. Unless it's already been implemented in OpenWRT.

Nitroshift and I have similar results as well. 930-940mbps without any additions to OpenWrt. My router has no load on it (not even WiFi) when I'm testing, which could have some effect on freeing up CPU time for routing. The thing is, any sort of latency or real-world effect quickly destroys that 900+.

I recall that poking around the Marvell kernel source in the factory firmware (v1 and v2) that NFP wasn't enabled in more recent releases. The CPU is fast enough with their driver (and its more advanced offloading) that it's not necessary. I can go back and look sometime. To be clear, it's using offloading to reduce CPU load when receiving/transmitting packets, but there are no hooks around the netfilter/routing/NAT subsystem as actual NFP requires.

So, "shouldn't be possible" is incorrect, and there are plenty of us (doing the test correctly) who have these numbers.

(Last edited by leitec on 10 Jun 2016, 16:54)

Interesting I will load OpenWRT on a couple of different WRT1900\1200AC router's and do some speed testing

Yeah, give it a shot. It's hit-or-miss, though. I meant to add that I have those results between my desktop and two different laptops serving as the iperf server. But a third has absolutely garbage performance through OpenWrt (200-300mbps and very jittery, high packet loss), but hits 900+ with no loss through the factory FW.

Edit: it's basically academic, I suppose. I don't think many people will hit that number with their real-world Internet connection.

(Last edited by leitec on 10 Jun 2016, 17:13)

I'm curious about this. Could you post what your config looks like with the ports/interfaces switched, resulting in a non-working router?

In the past I've done some throughput testing with real world downloading through NAT (Video files for example).

1. Without the BM patch on V1 hardware -- 650-750mbps sustained. (There were times I was able to get a bit more by messing with /proc/affinity).

2. With the BM patch on V1 hardware 850-950mbps sustained.

However, processor utilization was 90%+ to do it with both scenarios. So, it would be nice to have HW acceleration so that the processor doesn't get so taxed.

Thanks for the info. I will test with and without the BM patch.

it would be great to know if you come up with the same numbers or not.

@Chadster766 Build the latest lede it builds with hwbm and marvell-cesa crypto(not that you need this for this per say)

Will do :-)

McDebian/kernel-4.6.2 + BM

root@WRT1900ac:~# iperf3 -c 192.168.1.101
Connecting to host 192.168.1.101, port 5201
[  4] local 192.168.1.1 port 37196 connected to 192.168.1.101 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.01   sec  89.7 MBytes   747 Mbits/sec    0    211 KBytes
[  4]   1.01-2.00   sec   111 MBytes   937 Mbits/sec    0    211 KBytes
[  4]   2.00-3.01   sec   113 MBytes   936 Mbits/sec    0    211 KBytes
[  4]   3.01-4.00   sec   111 MBytes   937 Mbits/sec    0    222 KBytes
[  4]   4.00-5.00   sec   111 MBytes   936 Mbits/sec    0    222 KBytes
[  4]   5.00-6.00   sec   111 MBytes   930 Mbits/sec    0    222 KBytes
[  4]   6.00-7.00   sec   111 MBytes   936 Mbits/sec    0    222 KBytes
[  4]   7.00-8.01   sec   112 MBytes   937 Mbits/sec    0    222 KBytes
[  4]   8.01-9.00   sec   111 MBytes   935 Mbits/sec    0    222 KBytes
[  4]   9.00-10.00  sec   112 MBytes   937 Mbits/sec    0    222 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.07 GBytes   917 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.07 GBytes   916 Mbits/sec                  receiver

Sorry, I have no way to check the wan - lan. Basically, the results are similar.

@Chadster766

I think porting neta driver with all its offload modules into OpenWRT is doable, the only problem is time.

nitroshift

(Last edited by nitroshift on 11 Jun 2016, 07:14)

Switch/VLAN config:

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option vid '100'
    option ports '4 5t'

config switch_vlan
    option device 'switch0'
    option vlan '2'
    option vid '2'
    option ports '2 3 6t'

config switch_vlan
    option device 'switch0'
    option vlan '3'
    option vid '3'
    option ports '0 6t'

config switch_vlan
    option device 'switch0'
    option vlan '4'
    option vid '4'
    option ports '1 6t'

Interfaces (working)

config interface 'lan'
    option type 'bridge'
    option ifname 'eth1.2'
    option proto 'static'
    option netmask '255.255.255.0'
    option ipaddr '192.168.0.254'
    option ip6assign '64'

config interface 'isolated'
    option ifname 'eth1.3'
    option proto 'static'
    option ipaddr '192.168.1.254'
    option netmask '255.255.255.0'
    option ip6assign '64'
    option _orig_bridge 'false'

config interface 'WLAN'
    option proto 'static'
    option ipaddr '192.168.2.254'
    option netmask '255.255.255.0'
    option ip6assign '64'
    option _orig_ifname 'eth1.4'
    option _orig_bridge 'false'
    option ifname 'eth1.4'

config interface 'wan'
    option proto 'static'
    option ipaddr '192.168.178.2'
    option gateway '192.168.178.1'
    option dns '84.200.69.80 84.200.70.40'
    option _orig_ifname 'eth0'
    option _orig_bridge 'false'
    option netmask '255.255.255.252'
    option ifname 'eth0.100'

Interfaces example not working:

config interface 'lan'
    option type 'bridge'
    option ifname 'eth0.2'
    option proto 'static'
    option netmask '255.255.255.0'
    option ipaddr '192.168.0.254'
    option ip6assign '64'

config interface 'isolated'
    option ifname 'eth0.3'
    option proto 'static'
    option ipaddr '192.168.1.254'
    option netmask '255.255.255.0'
    option ip6assign '64'
    option _orig_bridge 'false'

config interface 'WLAN'
    option proto 'static'
    option ipaddr '192.168.2.254'
    option netmask '255.255.255.0'
    option ip6assign '64'
    option _orig_ifname 'eth1.4'
    option _orig_bridge 'false'
    option ifname 'eth0.4'

config interface 'wan'
    option proto 'static'
    option ipaddr '192.168.178.2'
    option gateway '192.168.178.1'
    option dns '84.200.69.80 84.200.70.40'
    option _orig_ifname 'eth0'
    option _orig_bridge 'false'
    option netmask '255.255.255.252'
    option ifname 'eth0.100'

(Last edited by shm0 on 10 Jun 2016, 21:33)

Are you sure you are not hitting this bug while bridging multiple VLAN's?
https://dev.openwrt.org/ticket/8701

Just found about that bug today  .. .and was able to fix it on the WNDR3700 as mentioned in the bug report.
Just be carefull .. because it depend on your hardware supporting the FID option.

Kees D.

Has anyone noticed when doing an iperf3 connection speed tanking?
There is no else on 5gkz in range. I let stabilize before testing on a reboot. and this is what I see.
No NetData or other bogging me down....Not that I know of anyway.
<<Marvell 802.11ac Wireless Network Driver version 10.3.0.17-20160608>>
Wrt1900acv1. 1 watt 3 meters away. This has been happening here for awhile......

https://onedrive.live.com/redir?resid=E … hoto%2cPNG

I haven't had any problems like that with V1 or ACS (so far).

Have you looked to see if anyone else is using the frequency?

"There is no else on 5gkz in range"  I have used acrylic and the router to verify"
Try watching status - overview - Associated Stations during a iperf3 test..
No trying to be a smart arse  But I see it there at a 5 sec refresh rate.

Edit: 5Ghz

(Last edited by northbound on 11 Jun 2016, 04:21)

When you tried on the other Ethernet port, did you also flip the switch VLAN assignments accordingly? (i.e. swap 5t and 6t where appropriate)

The driver doesn't support setting the FID via swconfig. It defaults to the VLAN number (1-64, which doesn't necessarily correspond to the VID that's send out on tagged packets) so that each VLAN has its own forwarding database.

Idle

root@1900acs:~# ps | awk -F " " '{ print $3, $0 }' | sort -nr | cut -d " " -f 2- | head
1510 root      4664 S    /usr/bin/mjpg_streamer --input input_uvc.so --device /dev/video2 --fps 30 --resolution 752x416 --led o
1509 root      4644 S    /usr/bin/mjpg_streamer --input input_uvc.so --device /dev/video1 --fps 30 --resolution 752x416 --led o
1508 root      4576 S    /usr/bin/mjpg_streamer --input input_uvc.so --device /dev/video0 --fps 30 --resolution 752x416 --led o
1540 root      3384 S    /usr/sbin/openvpn --syslog openvpn(lan) --status /var/run/openvpn.lan.status --cd /var/etc --config op
1496 root      2684 S    /usr/sbin/nmbd -F
1495 root      2624 S    /usr/sbin/smbd -F
1403 root      1960 S    /usr/sbin/uhttpd -f -h /www -r 1900acs -x /cgi-bin -u /ubus -t 60 -T 30 -k 20 -A 1 -n 3 -N 100 -R -p 0
2125 root      1588 S    /usr/sbin/hostapd -P /var/run/wifi-phy0.pid -B /var/run/hostapd-phy0.conf
1725 root      1588 S    /usr/sbin/hostapd -P /var/run/wifi-phy1.pid -B /var/run/hostapd-phy1.conf
1226 root      1552 S    /sbin/netifd

1900acs:~# free -m
             total       used       free     shared    buffers     cached
Mem:        513496      75080     438416       1060       5572      15060
-/+ buffers/cache:      54448     459048
Swap:      1048572          0    1048572
root@1900acs:~#

Do you think the linux-marvell driver mvebu_net actually has the NFP?

A quick search through the tree in Github shows that some of the code is there, but there isn't anything enabled by CONFIG_MV_ETH_NFP in the netfilter source code. So, I think it's not actually there.

To follow up on what I mentioned yesterday about NFP not being enabled in recent factory firmware builds, the .config included with the WRT1200 tarball has it off:

WRT1200_v1.0.4.166869_build5/src/linux/linux.config

# CONFIG_MV_ETH_NFP is not set

The Linux tree included with that appears superficially similar to the Github repo.

edit: this is also the case for the WRT1900ACv1, at least in this version:

/WRT1900AC-v1.1.8.164461-RC4/src/linux/linux.config

# CONFIG_MV_ETH_NFP is not set

edit 2: confirmed via extract-ikconfig on the kernel binary from FW_WRT1900AC_1.1.10.167514_prod.img.

(Last edited by leitec on 11 Jun 2016, 14:49)

I think Linksys modifies the kernel .config before releasing the GPL tars because AFAIK the GPL's for new model WRT's are not buildable.

In linux-marvell mvebu_net driver file mvNeta.h the CONFIG_MV_ETH_NFP does activate a lot of NFP code:

#ifdef CONFIG_MV_ETH_NFP

#ifdef CONFIG_MV_ETH_NFP_EXT
# define NFP_EXT_NUM     CONFIG_MV_ETH_NFP_EXT_NUM
#else
# define NFP_EXT_NUM     0
#endif

#define NFP_MAX_PORTS   (MV_ETH_MAX_PORTS + NFP_EXT_NUM)

typedef struct {
    void   *dev;
    MV_U32 tx_cmd;
    MV_U32 diffL4[2];
    MV_U8  *pWrite;
    MV_U16 flags;
    MV_U16 mtu;
    short  shift;
    MV_U8  txp;
    MV_U8  txq;
    MV_IP_HEADER_INFO ipInfo;
    void   *privateData;
} MV_NFP_RESULT;

#define MV_NFP_RES_TXP_VALID       0x0001
#define MV_NFP_RES_TXQ_VALID       0x0002
#define MV_NFP_RES_IP_INFO_VALID   0x0004
#define MV_NFP_RES_NETDEV_EXT      0x0010
#define MV_NFP_RES_L4_CSUM_NEEDED  0x0020

#endif /* CONFIG_MV_ETH_NFP */

In my second edit I extracted the actual .config from the firmware Linksys ships. It's embedded in the kernel binary. I used binwalk to extract the kernel and then ran extract-ikconfig on it. It's not from the GPL tarball.

That's within the network driver itself and it's just a few definitions in a header file. NFP works in part by bypassing Linux's NAT/routing path and replacing it with its own faster code. Compare the number of entries in net/netfilter with CONFIG_MV_ETH_NFP in the WRT1900AC v1 3.2 kernel source tree, e.g.

./nf_conntrack_core.c:#if defined(CONFIG_MV_ETH_NFP_HOOKS)

with their complete absence in this later kernel source. Marvell itself seems to be moving away from NFP. Their driver (the one in their source, unfortunately not the one upstream yet) is fast enough with their modern CPUs.

Great I didn't know that Linksys put the config in the kernel. Good job, I guess I wasted a couple of days trying to port the mvebu_net driver :-(