Re: [PATCH] neigh: Support filtering neighbours for L3 slave

[David Ahern <dsahern@gmail.com>]

On 8/3/21 12:47 AM, Lahav Schlesinger wrote:
>>>> you can not special case VRFs like this, and such a feature should apply
>>>> to links and addresses as well.
>>>
>>> Understandable, I'll change it.
>>> In this case though, how would you advice to efficiently filter
>>> neighbours for interfaces in the default VRF in userspace (without
>>> quering the master of every interface that is being dumped)?
>>> I reckoned that because there's support in iproute2 for filtering based
>>> on a specific VRF, filtering for the default VRF is a natural extension
>>
>> iproute2 has support for a link database (ll_cache). You would basically
>> have to expand the cache to track any master device a link is associated
>> with and then fill the cache with a link dump first. It's expensive at
>> scale; the "no stats" filter helps a bit.
>>
>> This is the reason for kernel side filtering on primary attributes
>> (coarse grain filtering at reasonable cost).
>>
> 
> Nice, didn't know about the ll_cache.
> Does filtering based on being in the default VRF is something you think
> can be merged into iproute2 (say with "novrf" keyword, following the "nomaster"
> convention below - e.g. "ip link show novrf")?
> If so I'll add it as a patch to iproute2.

yes. There is also an outstanding request to show the vrf of neighbor
entries (e.g., add a new column at the end with vrf) when doing a full dump.