On Wed, 2006-28-06 at 15:01 +0200, Thomas Graf wrote: > * jamal <[EMAIL PROTECTED]> 2006-06-28 08:22 [..] > > 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. > > It's using rt_iif which is currently derived from skb->dev even > though it would make sense to use skb->iif once that is well > defined. >
Why not use iflink? It exists, by definition, specifically as "the ifindex of the down muxed netdevice" (should probably add that definition in the .h). This is semantically different from a message to the stack which says "this came to you from input device X" (represented by input_dev). > > 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. > > What's special about that? It seems a perfectly fine and simple way > to create namespaces for sockets without enforcing applications to > bind to the correct vlan devices directly. > Can you achieve the same by binding to any arbitrary netdevice? If you can then i would agree. > This is clear, my question was for you to explain when you intend > to update input_dev etc. By overwriting it in ifb you enforce that > valueable information is lost. It is design intent for this field to carry information on where the packet came from. We may loop many times between devices (between ingress->egress or ingress->ingress, within the ttl limit) and each time the only meaningful thing is which was the last netdevice that was sending it. > There is nothing wrong with updating iif to point to ifb under > certain circumstances but it's not required to strictly enforce > this. Having mirred do so conditionally is a lot more flexible > without losing any value. > Refer to what i said above. > > 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? > > This statement doesn't make sense, it merely transforms a device > reference to a reference by interface index because the current > method of handling it doesn't make sense at all since the region > where input_dev stays valid without the risk of the device > disappearing is very limited. > Please refer to what i said above in that you could end up redirecting many times. I have not added yet the code which allows mirred to also do ingress redirection which would make it even more interesting. The challenge is this, and if you can solve it we would be fine: - I need to access both the input_dev and dev and their metadata. I could clearly find them by their ifindices and then reference them after that. For performance reasons that is not optimal in the fast path. [Note, we have had this discussion before and even then we came to some consensus that it would be hard to achieve that hence my view, again, to drop this]. > > It does work as it is right now (I only notice a pull - there is no > > push). > > In order to pull in ifb you need to push in mirred, quite > obvious, no? I think that my thinking at the time was that ifb can only receive packets via mirred and therefore the pull on ingress at ifb may have been to counter the push that occurs at mirred. Let me look at my notes and testcases when i get back home; it may make sense not to have it at ifb - the fact that it works as is tells me there is more to it than the obvious. > Why are you enforcing users of ifb to fake an > ethernet header that is of no use at all? This may just be an artifact of inheriting things from dummy device. The answer will be clear when i look at my notes. 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
