• Julian Anastasov's avatar
    ipv4: some rt_iif -> rt_route_iif conversions · 97a80410
    Julian Anastasov authored
    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: default avatarJulian Anastasov <ja@ssi.bg>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    97a80410
route.c 82.2 KB