[technique] [Fwd: Re: [LEDE-DEV] A state of network acceleration / test on Archer C7 v4]

[Laurent GUERBY]

FYI (4.4 => 4.9 pour le kernel)

-------- Forwarded Message --------
From: Laurent GUERBY <laurent at guerby.net>
To: Pablo Neira Ayuso <pablo at netfilter.org>, Rafał Miłecki <zajec5 at gmai
l.com>
Cc: LEDE Development List <lede-dev at lists.infradead.org>
Subject: Re: [LEDE-DEV] A state of network acceleration / test on
Archer C7 v4
Date: Sun, 28 Jan 2018 21:43:29 +0100


On Wed, 2018-01-17 at 19:30 +0100, Pablo Neira Ayuso wrote:
> Hi Rafal,
> 
> On Wed, Jan 17, 2018 at 04:25:10PM +0100, Rafał Miłecki wrote:
> > Getting better network performance (mostly for NAT) using some kind
> > of
> > acceleration was always a hot topic and people are still
> > looking/asking for it. I'd like to write a short summary and share
> > my
> > understanding of current state so that:
> > 1) People can undesrtand it better
> > 2) We can have some rough plan
> > 
> > First of all there are two possible ways of accelerating network
> > traffic: in software and in hardware. Software solution is
> > independent
> > of architecture/device and is mostly just bypassing in-kernel
> > packets
> > flow. It still uses device's CPU which can be a bottleneck. Various
> > software implementations are reported to be faster from 2x to 5x.
> 
> This is what I've been observing for the software acceleration here,
> see slide 19 at:
> 
> https://www.netdevconf.org/2.1/slides/apr8/ayuso-netdev-netfilter-upd
> ates-canada-2017.pdf
> 
> The flowtable representation, in software, is providing a faster
> forwarding path between two nics. So it's basically an alternative to
> the classic forwarding path, that is faster. Packets kick in at the
> Netfilter ingress hook (right at the same location as 'tc' ingress),
> if there is a hit in the software flowtable, ttl gets decremented,
> NATs are done and the packet is placed in the destination NIC via
> neigh_xmit() - through the neighbour layer.

Hi Pablo,

I tested today a few things on a brand new TP-Link Archer C7 v4.0,
LAN client Dell Latitude 7480 (eth I219-LM, wifi 8265 / 8275)
WAN server NUC5i3RYB (eth I218-V), NAT between them, <1 ms latency
(everything on the same table), IPv4 unless specified,
using iperf3 LAN=>WAN and -R for WAN=>LAN (both TCP).

With the TP-Link firmware:
- wired 930+ Mbit/s both ways
- wireless 5G 560+ Mbit/s down 440+ Mbit/s up
- wireless 2.4G 100+ Mbit/s both ways

With OpenWRT/LEDE trunk 20180128 4.4 kernel:
- wired 350-400 Mbit/s both ways
- wired with firewall deactivated 550 Mbit/s
  (just "iptables -t nat -A POSTROUTING -j MASQUERADE")
- wired IPv6 routing, no NAT, no firewall 250 Mbit/s
- wireless 5G 150-200 Mbit/s
- wireless 2.4G forgot to test

top on the router shows sirq at 90%+ during network load, other load
indicators are under 5%.

IPv6 performance without NAT being below IPv4 with NAT seems
to indicate there are potential gains in software :).

I didn't test OpenWRT in bridge mode but I got with LEDE 17.01
on an Archer C7 v2 about 550-600 Mbit/s iperf3 so I think
radio is good on these ath10k routers.

So if OpenWRT can do about x2 in software routing performance we're
good against our TP-Link firmware friends :).

tetaneutral.net (not-for-profit ISP, hosting OpenWRT and LEDE mirror in
FR) is going to install 40+ Archer C7 v4 running OpenWRT as CPE, each
with individual gigabit fiber uplink (TP-Link MC220L fiber converter),
and total 10G uplink (Dell/Force10 S4810 48x10G, yes some of our
members will get 10G on their PC at home :).

We build our images from git source, generating imagebuilder and then a
custom python script. We have 5+ spare C7, fast build (20mn from
scratch) and testing environment, and of course we're interested in
suggestions on what to do.

Thanks in advance for your help,

Sincerely,

Laurent
http://tetaneutral.net


_______________________________________________
Lede-dev mailing list
Lede-dev at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev