Re: [PATCH net-next] docs: netlink: clarify the historical baggage of Netlink flags

[Nikolay Aleksandrov <razor@blackwall.org>]

On 30/09/2022 19:36, Jamal Hadi Salim wrote:
> On Fri, Sep 30, 2022 at 10:34 AM Nikolay Aleksandrov
> <razor@blackwall.org> wrote:
>>
>> On 30/09/2022 17:24, Jamal Hadi Salim wrote:
>>> On Fri, Sep 30, 2022 at 7:29 AM Nikolay Aleksandrov <razor@blackwall.org> wrote:
> 
> [..]
> 
>>>
>>> I think what you are looking for is a way to either get or delete
>>> selective objects
>>> (dump and flush dont filter - they mean "everything"); iow, you send a filtering
>>
>> They must be able to flush everything, too. Filter matching all/empty filter, we need
>> it for mdbs and possibly other object types would want that.
> 
> You only have one object type though per netlink request i.e you
> dont have in the same message fdb and mdb objects?
> 

Yep, it is object-type and family- specific, as is the call itself.

>>> expression and a get/del command alongside it. The filtering
>>> expression is very specific
>>> to the object and needs to be specified as such a TLV is appropriate.
>>>
>>
>> Right, and that is what got implemented. The filtering TLVs are bridge and fdb-specific
>> they don't affect any other subsystem. The BULK flag denotes the delete will
>> affect multiple objects.
>>
> 
> Isnt it sufficient to indicate what objects need to be deleted based on presence
> of TLVs or the service header for that object?
> 

That was my initial proposal for the fdbs. :)  When flush attribute was present it would
act on it (and filter based on embedded filters). The only non-intuitive part was that it
happened through SETLINK (changelink), which is a bit strange for a delete op.

>>> Really NLM_F_ROOT and _MATCH are sufficient. The filtering expression is
>>> the challenge.
>>
>> NLM_F_ROOT isn't usable for a DEL expression because its bit is already used by NLM_F_NONREC
>> and it wouldn't be nice to change meaning of the bit based on the subsystem. NLM_F_MATCH's bit
>> actually matches NLM_F_BULK :)
>>
> 
> Ouch. Ok, it got messy over time i guess. We probably should have
> spent more time
> discussing NLM_F_NONREC since it has a single user with very specific
> need and it
> got imposed on all.
> I get your point - i am still not sure if a global flag is the right answer.
> 

Personally, I prefer the complete netlink approach (tlvs describing the operation and filters).
In the end the flag was close enough, I kept all of the family specific code the same just the entry
point was different and other families could use it as a modifier to their del commands.

>>
>> Sometime back I played with a different idea - expressing the filters with the existing TLV objects
>> so whatever can be specified by user-space can also be used as a filter (also for filtering
>> dump requests) with some introspection. The lua idea sounds nice though.
> 
> So what is the content of the TLV in that case?

My first approach, which wasn't using bpf, used the tlv type to define specific filters on the various
types, incl. binary (which at the time was only an exact match, could be improved though). BPF w/ btf
would be the obvious choice these days.

> I think ebpf may work with some acrobatics. We did try classical ebpf and it was
> messy. Note for scaling, this is not just about Delete and Get but
> also for generated
> events, where one can send to the kernel a filter so they dont see a broadcast

Yeah, I remember CL having scaling issues in some user-space software that was snooping
netlink messages and that's the reason I looked into filtering at that time.

> of everything. See for example a use case here:
> https://www.files.netdevconf.info/d/46fd7e152d1d4f6c88ac/files/?p=/LargeScaleTCPAnalytics.pdf
> 
> cheers,
> jamal