[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181002110259.tqh4uz46g3ihakir@brauner.io>
Date: Tue, 2 Oct 2018 13:03:00 +0200
From: Christian Brauner <christian@...uner.io>
To: Jiri Benc <jbenc@...hat.com>
Cc: David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org,
davem@...emloft.net, stephen@...workplumber.org,
David Ahern <dsahern@...il.com>
Subject: Re: [PATCH RFC v2 net-next 02/25] net/ipv6: Refactor address dump to
push inet6_fill_args to in6_dump_addrs
On Tue, Oct 02, 2018 at 12:54:25PM +0200, Jiri Benc wrote:
> On Mon, 1 Oct 2018 17:28:28 -0700, David Ahern wrote:
> > Pull the inet6_fill_args arg up to in6_dump_addrs and move netnsid
> > into it. Since IFA_TARGET_NETNSID is a kernel side filter add the
> > NLM_F_DUMP_FILTERED flag so userspace knows the request was honored.
>
> IFA_TARGET_NETNSID is not a filter.
Well, it's a namespace filter that's how I saw it.
>
> "Filter" returns a subset of the results. It's kind of optimization
That's an argument I can buy.
> when one is interested only in some data but not all of them. Instead
> of dumping everything, going through the results and picking only the
> data one is interested in, it's better to pass a filter and get only
> the relevant data. But you're not really required to: you can filter in
> your app.
>
> By contrast, IFA_TARGET_NETNSID returns a completely different set of
> data. It's impossible to not set it and filter the results in your app.
>
> As the consequence, IFA_TARGET_NETNSID must not set NLM_F_DUMP_FILTERED
> (if not complemented by a real filter).
>
> I understand that you want to differentiate between data dumped without
> and with IFA_TARGET_NETNSID present. But we already have that: the
> IFA_TARGET_NETNSID attribute is returned back in the latter case.
>
> Nacked-by: Jiri Benc <jbenc@...hat.com>
>
> Jiri
Powered by blists - more mailing lists