From: Jacob Keller <jacob.e.keller@intel.com>
To: Jiri Pirko <jiri@resnulli.us>, <netdev@vger.kernel.org>
Cc: <kuba@kernel.org>, <pabeni@redhat.com>, <davem@davemloft.net>,
<edumazet@google.com>, <jhs@mojatatu.com>,
<johannes@sipsolutions.net>, <andriy.shevchenko@linux.intel.com>,
<amritha.nambiar@intel.com>, <sdf@google.com>
Subject: Re: [patch net-next 3/8] devlink: send notifications only if there are listeners
Date: Wed, 15 Nov 2023 12:17:17 -0800 [thread overview]
Message-ID: <63a83bf7-b2d3-4af6-b87b-4e166fa22744@intel.com> (raw)
In-Reply-To: <20231115141724.411507-4-jiri@resnulli.us>
On 11/15/2023 6:17 AM, Jiri Pirko wrote:
> +static inline bool devlink_nl_notify_need(struct devlink *devlink)
> +{
> + return genl_has_listeners(&devlink_nl_family, devlink_net(devlink),
> + DEVLINK_MCGRP_CONFIG);
> +}
> +
I assume following changes will add more checks here to filter here so
it doesn't make sense to call this "devlink_has_listeners"? I feel like
the devlink_nl_notify_need is a bit weird of a way to phrase this.
I don't have a strong objection to the name overall, just found it a bit
odd.
> /* Notify */
> void devlink_notify_register(struct devlink *devlink);
> void devlink_notify_unregister(struct devlink *devlink);
> diff --git a/net/devlink/health.c b/net/devlink/health.c
> index 695df61f8ac2..93eae8b5d2d3 100644
> --- a/net/devlink/health.c
> +++ b/net/devlink/health.c
> @@ -496,6 +496,9 @@ static void devlink_recover_notify(struct devlink_health_reporter *reporter,
> WARN_ON(cmd != DEVLINK_CMD_HEALTH_REPORTER_RECOVER);
> ASSERT_DEVLINK_REGISTERED(devlink);
>
> + if (!devlink_nl_notify_need(devlink))
> + return;
> +
> msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> if (!msg)
> return;
> diff --git a/net/devlink/linecard.c b/net/devlink/linecard.c
> index 9d080ac1734b..45b36975ee6f 100644
> --- a/net/devlink/linecard.c
> +++ b/net/devlink/linecard.c
> @@ -136,7 +136,7 @@ static void devlink_linecard_notify(struct devlink_linecard *linecard,
> WARN_ON(cmd != DEVLINK_CMD_LINECARD_NEW &&
> cmd != DEVLINK_CMD_LINECARD_DEL);
>
> - if (!__devl_is_registered(devlink))
> + if (!__devl_is_registered(devlink) || !devlink_nl_notify_need(devlink))
> return;
>
A bunch of callers are checking both if its registered and a
notification is needed, does it make sense to combine this? Or I guess
at least a few places are notifying of removal after its no longer
registered, so we can't inline the devl_is_registered into the
devlink_nl_notify_need. Probably more clear to keep it separate too.
Ok.
next prev parent reply other threads:[~2023-11-15 20:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-15 14:17 [patch net-next 0/8] devlink: introduce notifications filtering Jiri Pirko
2023-11-15 14:17 ` [patch net-next 1/8] devlink: use devl_is_registered() helper instead xa_get_mark() Jiri Pirko
2023-11-15 20:11 ` Jacob Keller
2023-11-15 14:17 ` [patch net-next 2/8] devlink: introduce __devl_is_registered() helper and use it instead of xa_get_mark() Jiri Pirko
2023-11-15 20:11 ` Jacob Keller
2023-11-15 14:17 ` [patch net-next 3/8] devlink: send notifications only if there are listeners Jiri Pirko
2023-11-15 20:17 ` Jacob Keller [this message]
2023-11-16 7:14 ` Jiri Pirko
2023-11-15 14:17 ` [patch net-next 4/8] devlink: introduce a helper for netlink multicast send Jiri Pirko
2023-11-15 20:18 ` Jacob Keller
2023-11-15 14:17 ` [patch net-next 5/8] genetlink: implement release callback and free sk_user_data there Jiri Pirko
2023-11-15 14:17 ` [patch net-next 6/8] genetlink: introduce helpers to do filtered multicast Jiri Pirko
2023-11-15 14:53 ` Andy Shevchenko
2023-11-15 20:20 ` Jacob Keller
2023-11-16 7:15 ` Jiri Pirko
2023-11-15 14:17 ` [patch net-next 7/8] devlink: add a command to set notification filter and use it for multicasts Jiri Pirko
2023-11-15 14:17 ` [patch net-next 8/8] devlink: extend multicast filtering by port index Jiri Pirko
2023-11-15 15:08 ` Andy Shevchenko
2023-11-16 7:10 ` Jiri Pirko
2023-11-16 9:14 ` [patch net-next 0/8] devlink: introduce notifications filtering Jiri Pirko
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=63a83bf7-b2d3-4af6-b87b-4e166fa22744@intel.com \
--to=jacob.e.keller@intel.com \
--cc=amritha.nambiar@intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=johannes@sipsolutions.net \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.