Thomas Graf wrote: > * David Miller <[EMAIL PROTECTED]> 2006-06-26 10:46 > >>From: Patrick McHardy <[EMAIL PROTECTED]> >>Date: Mon, 26 Jun 2006 19:04:15 +0200 >> >> >>>I know this was discussed before, but I can't remember the >>>exact outcome. Why don't we just unconditionally update iif >>>in netif_receive_skb()? >> >>Software devices might have interesting semantics that would >>make not setting iif desirable. >> >>Once you set iif, you can't just undo it because the information >>is lost. >> >>I also would really prefer to set it unconditionally in >>netif_receive_skb(), but Jamal's concerns in this area are real. >>We really need to evaluate this on a case-by-case basis. > > > I'm playing with a FIFO device based on Jamal's previous > work to replace the broken IMQ device and provide real > queueing at ingress.
All my testing (quite a lot) in this area so far suggested that queueing at ingress doesn't work and is actually counter-productive. It gets worse with increasing signal propagation delays (signal in this case means congestion indications). I actually wish I never introduced the stupid IMQ device, it raises false hope and a lot of people seem to fall for it. > A set of VLAN devices could be redirected > to such a FIFO device and let applications bind to it in order > to implement trivial bind(INADDR_ANY) namespaces based on anything > that can be selected by classifiers. This example would benefit > from a conditional iif update (given that the mirred action is > extended to take a flag to steer this) so applications like a > dhcp daemon could use a raw socket on the FIFO device and thus > benefit from the bind namespace but still access the original > interface the packet was received from using pktinfo cmsg. > > Maybe silly but the best I could come up with :-) Doesn't sound too silly (actually quite nifty in my opinion), but I'm not sure I understand correctly, binding to ifb doesn't work since it changes both skb->dev and skb->input_dev. - 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
