ipv4: some rt_iif -> rt_route_iif conversions
authorJulian Anastasov <ja@ssi.bg>
Tue, 9 Aug 2011 04:01:16 +0000 (04:01 +0000)
committerDavid S. Miller <davem@davemloft.net>
Thu, 11 Aug 2011 12:58:59 +0000 (05:58 -0700)
commit97a804102021431fa6fa33c21c85df762b0f5cb9
treed5ac89119d3ba2c7d28deda9a8b7f46c4f0d86c1
parent5189054dd7ff18576446edc270b6b69fa8285336
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>
net/ipv4/route.c