Op 18/06/2013 16:11, Tsachi schreef:
The problem is that enabling bridge-nf-call-iptables, has an effect on
bridge traffic throughput:
96Mb/s when disabled.
70Mb/s when enabled.
First question:
When I check the same without bridge (routing + SNAT) throughput was 86Mb/s.
When bridge-nf-call-iptables is enabled, packets are going through L2
bridge code as well as L3 netfilter code, but, why it has such an
effects on the throughput?
I think to answer that will require performance profiling of the code,
since as far as I know it's never happened.
Here are some thoughts:
- W.r.t. ebtables, the performance impact of let's say a FORWARD chain
rule is bound to be higher for ebtables compared to iptables because it
will be called more for the same traffic. Fragmented IP packets, f.e.,
will be processed one by one by the FORWARD chain (if
bridge-nf-call-iptables is disabled) while an iptables FORWARD rule
would only be called once. Flooded packets are seen multiple times by
some ebtables chains (once for each output device). In the bridge-nf
case, these flooded packets are also seen multiple time by some iptables
chains.
- The function call stack is bigger in the bridge-nf compared to the
standard iptables case because we have the combination of NF_HOOKs for
NFPROTO_BRIDGE and NFPROTO_IPV4. NF_HOOK_THRESH adds to the equation.
Note that due to the design of netfilter, the call stack can grow quite
big because the NF_HOOK okfn is executed up the call stack.
Second question:
In order to share an IP (with iptables SNAT, without enabling
bridge-nf-call-iptables) ,
One solution I thought about, is to write a new ebtable module (used
in the brouting chain) which looks for the packet in the conntrack.
In case it finds it, Drop (routed) the packet, thus going through the
iptables code, if not found - Accept it (bridged).
This means some skb header work and conntrack searching for every
packet, do you think is a good approach?
What you could also try is making something based on br_netfilter.c that
only lets iptables connection tracking and POSTROUTING see the packets.
If you want full performance also for the traffic originating from the
bridge, it's best if you do your magic using brouting: traffic that
enters the IP stack through br0 is queued once more in the kernel than
traffic that enters the IP stack through one of the bridge ports (by
brouting the packet).
cheers,
Bart
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
