From: Thomas Graf <tgraf@suug.ch>
To: jamal <hadi@cyberus.ca>
Cc: Patrick McHardy <kaber@trash.net>,
David Miller <davem@davemloft.net>,
netdev@vger.kernel.org
Subject: Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
Date: Thu, 29 Jun 2006 10:51:11 +0200 [thread overview]
Message-ID: <20060629085111.GY1376@postel.suug.ch> (raw)
In-Reply-To: <1151502408.5203.94.camel@jzny2>
* jamal <hadi@cyberus.ca> 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.
next prev parent reply other threads:[~2006-06-29 8:50 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-26 14:54 [PATCHSET] Towards accurate incoming interface information Thomas Graf
2006-06-25 22:00 ` [PATCH 1/3] [NET]: Use interface index to keep input device information Thomas Graf
2006-06-25 22:00 ` [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device Thomas Graf
2006-06-26 17:04 ` Patrick McHardy
2006-06-26 17:46 ` David Miller
2006-06-26 18:24 ` Patrick McHardy
2006-06-26 18:44 ` Thomas Graf
2006-06-26 22:29 ` Patrick McHardy
2006-06-26 22:49 ` Patrick McHardy
2006-06-27 10:03 ` Thomas Graf
2006-06-27 13:07 ` jamal
2006-06-28 10:18 ` Thomas Graf
2006-06-28 12:22 ` jamal
2006-06-28 13:01 ` Thomas Graf
2006-06-28 13:46 ` jamal
2006-06-29 8:51 ` Thomas Graf [this message]
2006-06-29 20:55 ` Thomas Graf
2006-06-29 23:23 ` jamal
2006-06-29 23:39 ` Thomas Graf
2006-06-29 23:47 ` David Miller
2006-06-30 0:08 ` jamal
2006-06-30 0:12 ` David Miller
2006-06-30 0:26 ` jamal
2006-06-30 0:29 ` David Miller
2006-06-30 0:44 ` Ben Greear
2006-06-30 0:48 ` jamal
2006-06-30 0:55 ` Thomas Graf
2006-06-30 1:18 ` jamal
2006-06-30 0:03 ` jamal
2006-06-30 0:46 ` Thomas Graf
2006-06-30 1:11 ` jamal
2006-06-30 13:08 ` Thomas Graf
2006-06-30 13:20 ` Nicolas Dichtel
[not found] ` <44A52435.20909@6wind.com>
2006-06-30 13:36 ` Thomas Graf
2006-06-30 13:43 ` Nicolas Dichtel
2006-06-30 17:01 ` Patrick McHardy
2006-06-30 17:02 ` Patrick McHardy
2006-06-30 13:57 ` jamal
2006-06-30 14:15 ` Thomas Graf
2006-06-30 14:35 ` jamal
2006-06-30 15:40 ` Ben Greear
2006-06-30 16:32 ` Thomas Graf
2006-06-30 17:13 ` Thomas Graf
2006-06-30 17:18 ` Patrick McHardy
2006-06-30 17:32 ` jamal
2006-06-30 17:42 ` Patrick McHardy
2006-06-30 17:44 ` Thomas Graf
2006-06-30 19:40 ` jamal
2006-06-30 20:17 ` David Miller
2006-06-30 17:42 ` Thomas Graf
2006-06-30 19:34 ` jamal
2006-06-30 20:08 ` Thomas Graf
2006-06-30 20:42 ` jamal
2006-06-30 17:27 ` Ben Greear
2006-06-30 21:09 ` jamal
2006-06-30 21:20 ` Thomas Graf
2006-06-30 21:35 ` jamal
2006-06-30 23:22 ` Thomas Graf
2006-07-01 2:23 ` jamal
2006-07-01 11:51 ` Thomas Graf
2006-07-01 13:47 ` jamal
2006-06-30 17:19 ` jamal
2006-06-30 17:33 ` Patrick McHardy
2006-06-30 19:59 ` jamal
2006-06-30 20:30 ` Thomas Graf
2006-06-30 20:33 ` David Miller
2006-06-30 20:54 ` jamal
2006-06-30 21:10 ` Thomas Graf
2006-06-30 21:31 ` jamal
2006-06-30 23:45 ` Thomas Graf
2006-07-01 2:59 ` jamal
2006-07-01 11:28 ` Thomas Graf
2006-07-01 13:35 ` jamal
2006-07-08 10:54 ` Thomas Graf
2006-07-08 14:14 ` Jamal Hadi Salim
2006-07-08 14:29 ` Jamal Hadi Salim
2006-07-08 23:46 ` Thomas Graf
2006-07-08 23:48 ` Thomas Graf
2006-07-09 12:52 ` Jamal Hadi Salim
2006-07-09 13:17 ` Jamal Hadi Salim
2006-07-09 13:33 ` Thomas Graf
2006-07-09 14:03 ` Jamal Hadi Salim
2006-07-09 14:19 ` Thomas Graf
2006-07-09 15:00 ` Jamal Hadi Salim
2006-07-09 15:54 ` Thomas Graf
2006-07-09 23:06 ` Jamal Hadi Salim
2006-07-01 2:47 ` Patrick McHardy
2006-06-30 17:34 ` Thomas Graf
2006-06-25 22:00 ` [PATCH 3/3] [PKT_SCHED]: Add iif meta match Thomas Graf
2006-06-27 15:07 ` [PATCHSET] Towards accurate incoming interface information Thomas Graf
2006-06-27 20:24 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060629085111.GY1376@postel.suug.ch \
--to=tgraf@suug.ch \
--cc=davem@davemloft.net \
--cc=hadi@cyberus.ca \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).