[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpVoRuWgk6_x-MWj=A520XjpC3e2QoPspQG6pfd--+m=KA@mail.gmail.com>
Date: Fri, 4 Mar 2016 09:30:55 -0800
From: Cong Wang <xiyou.wangcong@...il.com>
To: Mahesh Bandewar <maheshb@...gle.com>
Cc: Mahesh Bandewar <mahesh@...dewar.net>,
David Miller <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
netdev <netdev@...r.kernel.org>, Tim Hockin <thockin@...gle.com>,
Alex Pollitt <alex.pollitt@...aswitch.com>,
Matthew Dupre <matthew.dupre@...aswitch.com>
Subject: Re: [PATCH next 3/3] net: Use l3_dev instead of skb->dev for L3 processing
On Thu, Mar 3, 2016 at 5:42 PM, Mahesh Bandewar <maheshb@...gle.com> wrote:
>>>> As you mentioned logically we should be able to pass the skb in master's
>>>> ns
>>>> until L3 processing is completed. This patch series attempts to do that by
>>>> disassociating this logic from skb->dev and adding it to l3_dev. This
>>>> should
>>>> include not just IPT but all that is done in L3 phase (IPT, routing etc.)
>>>> Also since dev->l3_dev is same as dev, this should not break any existing
>>>> logic.
>>>>
>>> Well, looking at the code I realized that I missed few places (especially
>>> routing
>>> logic) which continues using skb->dev in ingress path and should be
>>> corrected to
>>> use l3_dev. I'll correct those places and send the next version.
>>
>>
>> Look, even you yourself are missing something here. ;) This is exactly why
>> I suggest to consider another approach. Please don't introduce any code
>> that is hard to debug even for yourself. The struct net pointer is passed
>> around in kernel network subsystem almost everywhere, it is not easy to make
>> it bug-free by just switching skb->dev.
>>
> I disagree. Conceptually this is very easy to understand as we are taking L3
> processing off of skb->dev and loading it onto dev->l3_dev. So
> everything that is
> associated with l3_dev is for L3. This should neither make debugging harder
> nor add complicated code.
Nope, conceptually it is not right, that breaks _isolation_ in
concept, we need to
make each skb really traverse in the original stack, not just
switching skb->dev,
that is cheating. It is just too easy to hide bugs in your way, we
never use network
namespace in this way before.
Powered by blists - more mailing lists