[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1207240157120.2404@ja.ssi.bg>
Date: Tue, 24 Jul 2012 02:11:38 +0300 (EEST)
From: Julian Anastasov <ja@....bg>
To: David Miller <davem@...emloft.net>
cc: netdev@...r.kernel.org
Subject: Re: [PATCH 2/2] ipv4: Change rt->rt_iif encoding.
Hello,
On Mon, 23 Jul 2012, David Miller wrote:
> From: David Miller <davem@...emloft.net>
> Date: Mon, 23 Jul 2012 14:07:37 -0700 (PDT)
>
> > On input packet processing, rt->rt_iif will be zero if we should
> > use skb->dev->ifindex.
> >
> > Since we access rt->rt_iif consistently via inet_iif(), that is
> > the only spot whose interpretation have to adjust.
> >
> > Signed-off-by: David S. Miller <davem@...emloft.net>
>
> Julian, as you seem to have feared, this turns out to not work.
>
> We zap the skb->dev apparently, so I'll need to come up with
> a different scheme to handle this.
I was just replying that I don't see any problems
with the 4 patches but when you say it, may be the net/sched
code will work with output device on forwarding, not input.
Is skb_iif a good source? From include/linux/skbuff.h:
skb_iif: ifindex of device we arrived on
If it has hidden semantic may be we can make this
comment more specific, does it survive some loops?
Anyways, the idea for new encoding of rt_iif is very good.
Regards
--
Julian Anastasov <ja@....bg>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists