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-04-22 11:04:14 -07:00
2011-07-26 16:49:47 -07:00
2011-04-22 11:04:14 -07:00
2011-03-12 15:08:49 -08:00
2011-07-23 20:06:00 -07:00
2011-08-01 02:27:21 -07:00
2011-07-21 13:47:54 -07:00
2011-05-12 23:03:46 -04:00
2011-07-01 16:11:15 -07:00
2011-02-01 15:35:25 -08:00
2011-06-08 17:05:30 -07:00
2011-03-31 11:26:23 -03:00
2011-03-31 11:26:23 -03:00
2011-07-07 00:27:05 -07:00
2010-10-27 11:37:32 -07:00
2010-07-12 12:57:54 -07:00