Thread (87 messages) 87 messages, 6 authors, 2006-07-09

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

From: Thomas Graf <tgraf@suug.ch>
Date: 2006-06-26 18:44:05

* David Miller [off-list ref] 2006-06-26 10:46
From: Patrick McHardy <redacted>
Date: Mon, 26 Jun 2006 19:04:15 +0200
quoted
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. 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 :-)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help