Julian Anastasov 97a8041020 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>
2011-08-11 05:58:59 -07:00
..
2011-07-23 09:32:52 -05:00
2011-05-23 16:29:24 -04:00
2011-04-17 00:48:31 -07:00
2011-07-26 16:49:47 -07:00
2011-03-17 11:59:32 +11:00
2011-03-21 18:16:39 -07:00
2011-07-26 16:49:47 -07:00
2011-06-16 23:19:27 -04:00
2011-07-01 16:11:16 -07:00
2011-07-01 16:11:16 -07:00
2011-07-05 15:26:58 -04:00
2011-07-26 16:49:47 -07:00
2011-03-31 11:26:23 -03:00
2011-07-01 16:11:16 -07:00
2011-05-05 11:10:14 -07:00
2011-07-05 15:26:57 -04:00
2011-07-05 15:26:57 -04:00
2010-10-15 15:53:27 +02:00