Re: return of ip_rt_bug()

[Julian Anastasov <ja@ssi.bg>]

	Hello,

On Sun, 7 Aug 2011, David Miller wrote:

> commit 1b86a58f9d7ce4fe2377687f378fbfb53bdc9b6c
> Author: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> Date:   Thu Apr 7 14:04:08 2011 -0700
> 
>     ipv4: Fix "Set rt->rt_iif more sanely on output routes."

	I now checked these changes back to 2.6.38.
As rt_iif is used to provide input device even for loopback packets
that come with output route, may be we can optimize further
the code to save some CPU cycles. In fact, it restores
some route.c functions to 2.6.38 semantics. The conversion was:

fl.iif -> rt_route_iif
rt_iif -> preserved

	There are other places that used fl.iif (0 for output
routes) but are now using rt_iif instead of rt_route_iif,
not sure if this change is fatal for them because:

- net/sched/cls_route.c, route4_classify() gets optional
iif, so it can be 0, may be to match output route? And
later route4_classify does exact match for rt_iif. Does
it mean that now we can not match output packets without
providing "fromif OUTDEV" ?

- net/sched/em_meta.c: now int_rtiif (being rt_iif) is
always != 0, may be not good to match output routes?

	In short, the fl.iif -> rt_iif conversion is risky
at some places.

	For now posting patch for route.c in another thread...

Regards

--
Julian Anastasov <ja@ssi.bg>