Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

[jamal <hadi@cyberus.ca>]

On Wed, 2006-28-06 at 12:18 +0200, Thomas Graf wrote:
> * jamal <hadi@cyberus.ca> 2006-06-27 09:07
[..]
> > Note the meta-setter (been sitting on it for too long) also set the
> > input_dev.
> 
> Could you share that piece of code so I don't have to duplicate
> that effort?
> 

I will look it up and send it your way - it is not complete (I have
changed machines twice since i first wrote it). Or maybe the intent of
your question was to ask how was the setting of input_dev was done?

> > BTW, in regards to the VLANs, what is wrong with using the
> > netdev->iflink to figure the real device? 
> 
> 
> vlan1
>           ifb1
> vlan2
> vlan3
>           ifb2
> vlan4
> 
> dhcp daemon would bind to ifb1 and use pktinfo cmsg to figure
> out whether the packet was received on vlan1 or vlan2, the
> actual physical device is of no interest anymore.
> 

Let me see if i understood correctly:
you have a device from both vlan1 and vlan2 both being redirected to
ifb1? and vlan 3, 4=> ifb2?
And i take it to make it interesting vlan1,2 on eth0 and vlan3,4 ontop
of eth1? note the iflink would/should reflect eth1/2. If you had bonding
or bridging in between it gets more interesting. But you are saying
you are no longer interested in the info that it came via eth1/2 at some
point, correct? 
Note, in such a case: iflink rewriting will do it just fine
but then you loose the original info (I think it would be good to not
loose such info to know the origin). I dont know if cmsg uses iflink at
all - they probably look at the ifindex.

Ok, now question: why are you binding on top of ifb? we could have
redirected this to ipip, or tun0 or loopback or eql etc where it may
equally not have made sense to bind to. I can see something like this
making sense for bonding or bridging but not as a generic answer for all
netdevices.

> Looking at your ifb code I see that you set skb->dev based on
> iif and update iif unconditionally. I see a lot of problems
> with this, firstly iif is already updated in the mirred action,
> secondly iif doesn't necessarily point to the device the packet
> was last seen on. Could you maybe explain the policy of iif
> you have in mind, it doesn't seem very consistent.
> 

The concept is to use ifb as a transitionary device. Packets come into
it from either the ingress side of the stack or egress and get returned
on the same side/spot they were found - with ifb represented as the
input device. What ifb does is independent of what mirred does (we could
redirect to other devices other than ifb).
 
Now that i pay attention to your patch i think i see the complications
it is introducing (i am not done yet)- and i did warn about this in the
discussion _and_ didnt we agree to leave this stuff alone? Can we drop
this change please?

> BTW, why does ifb have a hard header length? The resulting
> push and pull only slows things down.

Good question. I know there were a lot of oddities i had to deal with
when different link layers cross over (some have smaller headers than
other and yet others had none ;->)
I will have to go and look at my notes test cases and get back to you; 

It does work as it is right now (I only notice a pull - there is no
push).

cheers,
jamal