On Wed, 2006-28-06 at 12:18 +0200, Thomas Graf wrote: > * jamal <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
