Mon, Jul 31, 2023 at 07:06:32PM CEST, kuba@kernel.org wrote:

On Mon, 31 Jul 2023 14:52:44 +0200 Jiri Pirko wrote:

quoted

quoted

This patch is not very clean. IMHO implementing the filters by skipping
is not going to scale to reasonably complex filters. Isn't it better to  

I'm not sure what do you mean by skipping? There is not skipping. In
case PORT_INDEX is passed in the selector, only that specific port is
processed. No scale issues I see. Am I missing something?

quoted

add a .filter callback which will look at the about-to-be-dumped object
and return true/false on whether it should be dumped?  

No, that would not scale. Passing the selector attrs to the dump
callback it better, as the dump callback according to the attrs can
reach only what is needed, knowing the internals. But perhaps I don't
understand correctly your suggestion.

for_each_obj() {
if (obj_dump_filtered(obj, dump_info))  // < run filter
	continue;                       // < skip object

dump_one(obj)

I don't see how this would help. For example, passing PORT_INDEX, I know
exactly what object to reach, according to this PORT_INDEX. Why to
iterate over all of them and try the filter? Does not make sense to me.

Maybe we are each understanding this feature differently. This is about
passing keys which index the objects. It is always devlink handle,
sometimes port index and I see another example in shared buffer index.
That's about it. Basically user passes partial tuple of indexes.
Example:
devlink port show
the key is: bus_name/dev_name/port_index
user passes bus_name/dev_name, this is the selector, a partial key.

The sophisticated filtering is not a focus of this patchset. User can do
it putting bpf filter on the netlink socket.