[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f67bebd9-24d8-69e1-0239-f4bc79ca0116@nvidia.com>
Date: Tue, 21 Sep 2021 10:43:34 +0300
From: Nikolay Aleksandrov <nikolay@...dia.com>
To: Stephen Suryaputra <ssuryaextr@...il.com>,
David Ahern <dsahern@...il.com>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH net-next] ipmr: ip6mr: Add ability to display non default
caches and vifs
On 21/09/2021 02:49, Stephen Suryaputra wrote:
> On Wed, Aug 18, 2021 at 06:04:12PM -0600, David Ahern wrote:
>> On 8/18/21 5:12 PM, Nikolay Aleksandrov wrote:
>>> I do not. You can already use netlink to dump any table, I don't see any point
>>> in making those available via /proc, it's not a precedent. We have a ton of other
>>> (almost any) information already exported via netlink without any need for /proc,
>>> there really is no argument to add this new support.
>>
>> agreed. From a routing perspective /proc files are very limiting. You
>> really need to be using netlink and table dumps. iproute2 and kernel
>> infra exist to efficiently request the dump of a specific table. What is
>> missing beyond that?
>
> On this, I realized now that without /proc the multicast caches can be
> displayed using iproute2. But, it doesn't seem to have support to
> display vifs. Is there a public domain command line utility that can
> display vifs on non default table, i.e. the one that uses the support in
> the kernel in commit 772c344dbb23 ("net: ipmr: add getlink support")?
>
> Thanks.
>
Not that I know of, this was supposed to be used by FRR but other things were
eventually given higher priority and it got sidelined. I'm sure at some point
we'll get to using it in iproute2. The netlink interface can also be used to
extend the number of vifs in a dynamic way, it'd be nice if we finally deprecated
the old static and non-extendable interface and started using netlink for ipmr.
Cheers,
Nik
Powered by blists - more mailing lists