summaryrefslogtreecommitdiff
path: root/COPYING
diff options
context:
space:
mode:
authorJulian Anastasov <ja@ssi.bg>2011-08-09 04:01:16 (GMT)
committerDavid S. Miller <davem@davemloft.net>2011-08-11 12:58:59 (GMT)
commit97a804102021431fa6fa33c21c85df762b0f5cb9 (patch)
treed5ac89119d3ba2c7d28deda9a8b7f46c4f0d86c1 /COPYING
parent5189054dd7ff18576446edc270b6b69fa8285336 (diff)
downloadlinux-97a804102021431fa6fa33c21c85df762b0f5cb9.tar.xz
ipv4: some rt_iif -> rt_route_iif conversions
As rt_iif represents input device even for packets coming from loopback with output route, it is not an unique key specific to input routes. Now rt_route_iif has such role, it was fl.iif in 2.6.38, so better to change the checks at some places to save CPU cycles and to restore 2.6.38 semantics. compare_keys: - input routes: only rt_route_iif matters, rt_iif is same - output routes: only rt_oif matters, rt_iif is not used for matching in __ip_route_output_key - now we are back to 2.6.38 state ip_route_input_common: - matching rt_route_iif implies input route - compared to 2.6.38 we eliminated one rth->fl.oif check because it was not needed even for 2.6.38 compare_hash_inputs: Only the change here is not an optimization, it has effect only for output routes. I assume I'm restoring the original intention to ignore oif, it was using fl.iif - now we are back to 2.6.38 state Signed-off-by: Julian Anastasov <ja@ssi.bg> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'COPYING')
0 files changed, 0 insertions, 0 deletions