* jamal <[EMAIL PROTECTED]> 2006-06-28 09:46
> 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).

I disagree, iflink information is bogus once we start redirecting.

> > 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.

It was your request to not update input_dev in netif_receive_skb()
but rather have each netdevice handle it manually. What's currently
done in ifb:

        skb->dev = skb->input_dev;
        skb->input_dev = dev;

Confusing, isn't it? I really don't get input_dev/iif is supposed to
be updated in ifb. If a packet is to be redirected, the mirred action
shall take care of providing this information to the next netdevice.
My additional request is to provide a flag to disable this for special
purposes not hurting anyone.

> 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.  

Nice, you forget that while redirecting the device pointed to by
input_dev can disappear leaving behind an illegal reference. The
purpose of this patch is to fix this.
-
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

Reply via email to