From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
To: Cong Wang <xiyou.wangcong@gmail.com>,
Mahesh Bandewar <maheshb@google.com>
Cc: Mahesh Bandewar <mahesh@bandewar.net>,
David Miller <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
netdev <netdev@vger.kernel.org>, Tim Hockin <thockin@google.com>,
Alex Pollitt <alex.pollitt@metaswitch.com>,
Matthew Dupre <matthew.dupre@metaswitch.com>,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH next 3/3] net: Use l3_dev instead of skb->dev for L3 processing
Date: Tue, 8 Mar 2016 10:46:47 +0100 [thread overview]
Message-ID: <56DE9F87.8060009@6wind.com> (raw)
In-Reply-To: <CAM_iQpXHHMvbOMO5iG8jhk5yz3CyxB0641FYhcRPA65HL7DLjA@mail.gmail.com>
+ Eric B.
Le 08/03/2016 06:37, Cong Wang a écrit :
> On Fri, Mar 4, 2016 at 2:12 PM, Mahesh Bandewar <maheshb@google.com> wrote:
>>
>> Unfortunately we don't have a way to switch to ns after L3 processing.
>
> I am totally aware of this, this is exactly why I said this might not be easy.
>
> The question is how hard it is to implement one? My gut feeling is we only
> need to change some data in skb, something similar to skb_scrub_packet().
> But I never even try.
Note that Eric Biederman has made "some" patches to be able to "control" the
netns on the egress side. The goal is to be able to have routes that leak to
another netns.
It seems that the same work should probably be done at the ingress side.
I agree with Cong that just changing skb->dev is not the right approach.
next prev parent reply other threads:[~2016-03-08 9:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-29 22:08 [PATCH next 3/3] net: Use l3_dev instead of skb->dev for L3 processing Mahesh Bandewar
2016-03-03 4:45 ` Cong Wang
2016-03-03 21:43 ` Mahesh Bandewar
[not found] ` <CAF2d9jiyjThgeQKw==tKRk3Sh0dNfzUdwJciwsVGPFLdb9uGTA@mail.gmail.com>
2016-03-04 0:44 ` Cong Wang
2016-03-04 1:42 ` Mahesh Bandewar
2016-03-04 17:30 ` Cong Wang
2016-03-04 22:12 ` Mahesh Bandewar
2016-03-08 5:37 ` Cong Wang
2016-03-08 9:46 ` Nicolas Dichtel [this message]
2016-03-08 18:42 ` Mahesh Bandewar
2016-03-10 0:09 ` Cong Wang
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=56DE9F87.8060009@6wind.com \
--to=nicolas.dichtel@6wind.com \
--cc=alex.pollitt@metaswitch.com \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=edumazet@google.com \
--cc=mahesh@bandewar.net \
--cc=maheshb@google.com \
--cc=matthew.dupre@metaswitch.com \
--cc=netdev@vger.kernel.org \
--cc=thockin@google.com \
--cc=xiyou.wangcong@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.