Timo Teräs wrote:
Yes. But my observation was that for the same amount of packets
sent locally the CPU usage is significantly higher than if they
are forwarded from physical interface. That's what made me
curious.
If I had remember that icmp conn track entries get pruned right
when they get icmp reply back, I would not have probably bothered
to bug you. But that made me think it was more of generic problem
than my patch.
I'll also double check with oprofile the local sendto() approach
where it dies.
Ok, finally figured out the difference. Looks like depending
on the sendto() / local route / forward route / my patched mrt
the skb that gets passed to ipgre_tunnel_xmit() seems to have
nfctinfo either 0 or 2. This value is not modified; nf_reset()
is called just before ip_local_out(). Looks like nf_reset()
clears nfct to NULL, but does not touch nfctinfo.
So when LOCAL_OUT hook for the GRE packet is hit, depending
where the packet came: it has nfct=NULL and nfctinfo=ESTABLISHED
or NEW. This also seems to affect if that specific skb gets
the nat/OUTPUT hook called.
Is this behaviour for nf_reset() intentional?
- Timo
--
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
