netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org, pabeni@redhat.com, davem@davemloft.net,
	edumazet@google.com, moshe@nvidia.com, saeedm@nvidia.com,
	idosch@nvidia.com, petrm@nvidia.com
Subject: Re: [patch net-next v2 11/11] devlink: extend health reporter dump selector by port index
Date: Mon, 31 Jul 2023 14:52:44 +0200	[thread overview]
Message-ID: <ZMeunKZscNRQTssp@nanopsycho> (raw)
In-Reply-To: <20230725114803.78e1ae00@kernel.org>

Tue, Jul 25, 2023 at 08:48:03PM CEST, kuba@kernel.org wrote:
>On Thu, 20 Jul 2023 14:18:29 +0200 Jiri Pirko wrote:
>> Introduce a possibility for devlink object to expose attributes it
>> supports for selection of dumped objects.
>> 
>> Use this by health reporter to indicate it supports port index based
>> selection of dump objects. Implement this selection mechanism in
>> devlink_nl_cmd_health_reporter_get_dump_one()
>
>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?


>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.

  reply	other threads:[~2023-07-31 12:52 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-20 12:18 [patch net-next v2 00/11] devlink: introduce dump selector attr and use it for per-instance dumps Jiri Pirko
2023-07-20 12:18 ` [patch net-next v2 01/11] devlink: parse linecard attr in doit() callbacks Jiri Pirko
2023-07-20 12:18 ` [patch net-next v2 02/11] devlink: parse rate attrs " Jiri Pirko
2023-07-20 12:18 ` [patch net-next v2 03/11] devlink: introduce __devlink_nl_pre_doit() with internal flags as function arg Jiri Pirko
2023-07-20 12:18 ` [patch net-next v2 04/11] devlink: convert port get command to split ops Jiri Pirko
2023-07-20 12:18 ` [patch net-next v2 05/11] devlink: convert health reporter " Jiri Pirko
2023-07-20 12:18 ` [patch net-next v2 06/11] devlink: convert param " Jiri Pirko
2023-07-20 12:18 ` [patch net-next v2 07/11] devlink: convert trap " Jiri Pirko
2023-07-20 12:18 ` [patch net-next v2 08/11] devlink: introduce set of macros and use it for split ops definitions Jiri Pirko
2023-07-25 17:38   ` Jakub Kicinski
2023-07-31 12:21     ` Jiri Pirko
2023-07-31 16:57       ` Jakub Kicinski
2023-08-01  6:41         ` Jiri Pirko
2023-07-20 12:18 ` [patch net-next v2 09/11] devlink: convert rest of the iterator dumpit commands to split ops Jiri Pirko
2023-07-20 12:18 ` [patch net-next v2 10/11] devlink: introduce dump selector attr and use it for per-instance dumps Jiri Pirko
2023-07-25 18:40   ` Jakub Kicinski
2023-07-31 12:47     ` Jiri Pirko
2023-07-31 17:03       ` Jakub Kicinski
2023-08-01  6:42         ` Jiri Pirko
2023-08-01 15:53           ` Jakub Kicinski
2023-08-02  7:02             ` Jiri Pirko
2023-07-20 12:18 ` [patch net-next v2 11/11] devlink: extend health reporter dump selector by port index Jiri Pirko
2023-07-25 18:48   ` Jakub Kicinski
2023-07-31 12:52     ` Jiri Pirko [this message]
2023-07-31 17:06       ` Jakub Kicinski
2023-08-01  6:49         ` Jiri Pirko
2023-08-01 15:56           ` Jakub Kicinski
2023-08-02  7:04             ` Jiri Pirko
2023-07-20 13:55 ` [patch net-next v2 00/11] devlink: introduce dump selector attr and use it for per-instance dumps Petr Machata
2023-07-20 14:27   ` Jiri Pirko
2023-07-20 14:51     ` Petr Machata
2023-07-25  8:07 ` Jiri Pirko
2023-07-25  8:36   ` Paolo Abeni
2023-07-25 15:29     ` Jiri Pirko
2023-07-25 16:39       ` Paolo Abeni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZMeunKZscNRQTssp@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=idosch@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=moshe@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=petrm@nvidia.com \
    --cc=saeedm@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).