netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: netdev@vger.kernel.org, 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: Thu, 16 Nov 2023 08:14:26 +0100	[thread overview]
Message-ID: <ZVXBUorPrSmd7UNl@nanopsycho> (raw)
In-Reply-To: <63a83bf7-b2d3-4af6-b87b-4e166fa22744@intel.com>

Wed, Nov 15, 2023 at 09:17:17PM CET, jacob.e.keller@intel.com wrote:
>
>
>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.

Right. I named it like this because eventually, this function is going
to check the filters as well return false if there is no msg passed to
any listening socket through any filter. That is the plan.


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

Yeah, it is more clear to have it separate. Plus there would have to be
2 locked and unlocked versions.


>
>Ok.

  reply	other threads:[~2023-11-16  7:14 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
2023-11-16  7:14     ` Jiri Pirko [this message]
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=ZVXBUorPrSmd7UNl@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=amritha.nambiar@intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jacob.e.keller@intel.com \
    --cc=jhs@mojatatu.com \
    --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 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).