On Mon, Mar 7, 2016 at 9:37 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Fri, Mar 4, 2016 at 2:12 PM, Mahesh Bandewar <mahe...@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. > >> So I would >> argue it the other-way around. The way it is now; breaks the _isolation_ >> model. >> If the default-ns is responsible for whole L3 (in this situation) and >> it does pretty well >> on egress but there is no way to do that in ingress path. IPtables is >> not the only thing, >> how about routing, how about IPsec? None of this will function well. >> So we need to >> have a generic solution to solve all these problems. > > I don't understand why you question me this, it is you who only cares > about iptables from your cover letter for this patchset, not me. > calm down! I'm not questioning you or anyone. There is problem and I would prefer to solve it properly without cooking-up some short-term hack. The problem reported is about IPtable and when I looked at it, I felt that it's just a matter of time until someone tries / uses IPsec or some routing. So I created this solution. I did mention about *complete* L3 processing in the cover letter but agree that I emphasized only on IPtables which I can correct it in the next version.
> The more subsystems involves, the more struct net pointers you > potentially need to touch, the less likely you can make it correct > by just switching skb->dev. Please drop that prejudice and read the patch-set carefully. I'm neither changing any *net* pointers nor changing the skb->dev pointers anywhere. All I'm saying is dev->l3_dev is what we'll use for *all* L3 processing and no need to change skb->dev or net-ns of any device(s) involved.
