aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/generic/pending-3.18/831-ledtrig_netdev.patch
diff options
context:
space:
mode:
authorDaniel Golle <daniel@makrotopia.org>2018-11-15 11:12:54 -0500
committerDaniel Golle <daniel@makrotopia.org>2018-11-25 15:24:49 +0100
commit51c094e7032b45522cc7060858196881e161e615 (patch)
tree22df9fee0f46ebce46a65bd8f49ae88b0e08fde0 /target/linux/generic/pending-3.18/831-ledtrig_netdev.patch
parent0bd99db5118665bbe17f84427238c322af3deaae (diff)
downloadupstream-51c094e7032b45522cc7060858196881e161e615.tar.gz
upstream-51c094e7032b45522cc7060858196881e161e615.tar.bz2
upstream-51c094e7032b45522cc7060858196881e161e615.zip
kernel: enable CONFIG_BRIDGE_VLAN_FILTERING
This allows us to use the bridge as a managed switch and gracefully handle mixed tagged and untagged frames. Prior to this, the only alternative was creating one bridge per vlan which quickly becomes a nightmare and still won't let you mix both tagged and untagged frames on the physical port without some complex ebtables magic. This is in line with the notion that OpenWRT is the network go-to swiss army knife when you need a nice set-and-forget, low maintenance box to handle a specific task. Current builds of the ip-bridge package already fully support this feature so the only requirement is enabling the kernel config. This is disabled by default so existing bridge configurations will not be affected. This patch only gives the ability to turn it on with an 'ip link' command. If there is interest, I could look into making the feature accessible via uci configuration. It causes about 3.1% hit on raw bridging speed, which is relatively trivial considering that I had to use 300 byte packets to strain the CPU enough to notice a slowdown at all. The ER8 would chug along at wire speed otherwise, and that's using only one core. Since the typical bridge use case on OpenWRT is wireless, I doubt it would be noticeable at all. With BRIDGE_VLAN_FILTERING iperf -u -c 192.168.1.105 -b 1G -l 300 ------------------------------------------------------------ Client connecting to 192.168.1.105, UDP port 5001 Sending 300 byte datagrams, IPG target: 2.24 us (kalman adjust) UDP buffer size: 208 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.12 port 58045 connected with 192.168.1.105 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 977 MBytes 820 Mbits/sec [ 3] Sent 3414986 datagrams [ 3] Server Report: [ 3] 0.0-10.0 sec 811 MBytes 680 Mbits/sec 0.000 ms 581210/3414986 (0%) Without BRIDGE_VLAN_FILTERING iperf -u -c 192.168.1.105 -b 1G -l 300 ------------------------------------------------------------ Client connecting to 192.168.1.105, UDP port 5001 Sending 300 byte datagrams, IPG target: 2.24 us (kalman adjust) UDP buffer size: 208 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.12 port 36645 connected with 192.168.1.105 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 977 MBytes 820 Mbits/sec [ 3] Sent 3414990 datagrams [ 3] Server Report: [ 3] 0.0-10.0 sec 836 MBytes 701 Mbits/sec 0.000 ms 493950/3414990 (0%) In terms of kernel size, it uses 16KB (6753K vs 6737K on ER8) so a 0.002% hit. The exact 16KB is probably just due to how the kernel is compressed. Suggested-by: Jonathan Thibault <jonathan@navigue.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Diffstat (limited to 'target/linux/generic/pending-3.18/831-ledtrig_netdev.patch')
0 files changed, 0 insertions, 0 deletions