On 30/09/2022 19:36, Jamal Hadi Salim wrote:

On Fri, Sep 30, 2022 at 10:34 AM Nikolay Aleksandrov
[off-list ref] wrote:

quoted

On 30/09/2022 17:24, Jamal Hadi Salim wrote:

quoted

On Fri, Sep 30, 2022 at 7:29 AM Nikolay Aleksandrov [off-list ref] wrote:

[..]

quoted

quoted

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.

quoted

quoted

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.

quoted

quoted

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.

quoted

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