[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpVDns-WLagoiAxVCmkohm9+QJF1so60++K5Qef-qOFx=w@mail.gmail.com>
Date: Wed, 12 Jul 2017 09:58:25 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: Neil Horman <nhorman@...driver.com>
Cc: martinbj2008@...il.com, David Miller <davem@...emloft.net>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
zhangjunweimartin@...ichuxing.com
Subject: Re: [PATCH v1 net-next 1/5] drop_monitor: import netnamespace framework
On Wed, Jul 12, 2017 at 6:37 AM, Neil Horman <nhorman@...driver.com> wrote:
> On Wed, Jul 12, 2017 at 06:40:49PM +0800, martinbj2008@...il.com wrote:
>> The dropwatch is a very useful tool to diagnose network problem,
>> which give us greate help.
>> Dropwatch could not work under container(net namespace).
>> It is a pitty, so let it support net ns.
>>
> Sorry, Im having a hard time wrapping my head around this. Why exactly is it
> that dropwatch won't work in a namespaced environment? IIRC, the kfree
> tracepoints are namespace agnostic, and so running dropwatch anywhere should
> result in seeing drops in all namespaces. I grant that perhaps it would be nice
> to filter on a namespace, but it should all 'just work' for some definition of
> the term, no?
Agreed.
And I doubt Martin's implementation which uses skb->sk to retrieve net
works for RX packets, since skb->sk is set very late (except with early demux)
on RX side but we can drop them at anytime...
Powered by blists - more mailing lists