[OpenWrt-Devel] [PATCH] generic: Fix per interface nf_call_iptables setting

[Sven Eckelmann]

On Wednesday 02 September 2015 19:47:43 Sven Eckelmann wrote:
[...]
> | kernel          | br-nf-* global | nf-call* iface | download | upload   |
> |-----------------|----------------|----------------|----------|----------|
> | default         | 0              | -              |      209 |      268 |
> | brfilter-global | 0              | -              |      185 |      243 |
> | brfilter-local  | 0              | -              |      187 |      243 |
> | brfilter-local  | 0              | br-lan         |      157 |      226 |
> | brfilter-local  | 0              | br-lan br-wlan |      139 |      161 |
> | brfilter-global | 1              | -              |      136 |      162 |

For people interested for the numbers in a simpler setup (only one bridge and
both eth0 and wlan0 in it):

| kernel          | br-nf-* global | nf-call* iface | download | upload   |
|-----------------|----------------|----------------|----------|----------|
| default         | 0              | -              |      235 |      252 |
| brfilter-global | 0              | -              |      229 |      254 |
| brfilter-local  | 0              | -              |      234 |      251 |
| brfilter-local  | 0              | br-lan         |      195 |      254 |
| brfilter-global | 1              | -              |      194 |      256 |

Download/upload results in Mibit/s

Of course, the br-filter local setup with bridge-nf-call-iptables enabled on
one bridge and disabled on the other bridge is not possible. This is the
reason why the routing test was more interesting for me.

But it can be seen quite good that the relative results for the download are
similar to the ones shown in the routing setup. But the results from the
upload test and the download results for the default kernel are more or less
useless because the wifi is the limiting factor. A barplot of the download
numbers is attached.

I've created a second test to make the CPU the limiting factor. Both eth0 and
wlan0 were added to an HTB filter qdisc limiting the performance to 1 Gibit/s.
This a lot more than the wifi chip can handle.

| kernel          | br-nf-* global | nf-call* iface | download | upload   |
|-----------------|----------------|----------------|----------|----------|
| default         | 0              | -              |      152 |      218 |
| brfilter-global | 0              | -              |      139 |      167 |
| brfilter-local  | 0              | -              |      140 |      170 |
| brfilter-local  | 0              | br-lan         |       97 |      120 |
| brfilter-global | 1              | -              |       94 |      116 |

Now both download and upload show the same relative results as shown in
initial routing test.

Kind regards,
	Sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2015-09-03_performance_download_bridging_brfilter_owrt.png
Type: image/png
Size: 24956 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20150903/8600466c/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20150903/8600466c/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel