From: Jiri Pirko <jiri@resnulli.us>
To: Moshe Shemesh <moshe@nvidia.com>
Cc: Moshe Shemesh <moshe@mellanox.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Jiri Pirko <jiri@mellanox.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next RFC v4 03/15] devlink: Add reload action stats
Date: Tue, 15 Sep 2020 15:33:09 +0200 [thread overview]
Message-ID: <20200915133309.GP2236@nanopsycho.orion> (raw)
In-Reply-To: <a5b7cbd5-ef55-1d74-a21e-5fb962307773@nvidia.com>
Tue, Sep 15, 2020 at 02:30:19PM CEST, moshe@nvidia.com wrote:
>
>On 9/14/2020 4:39 PM, Jiri Pirko wrote:
>> Mon, Sep 14, 2020 at 08:07:50AM CEST, moshe@mellanox.com wrote:
[..]
>> > +/**
>> > + * devlink_reload_implicit_actions_performed - Update devlink on reload actions
>> > + * performed which are not a direct result of devlink reload call.
>> > + *
>> > + * This should be called by a driver after performing reload actions in case it was not
>> > + * a result of devlink reload call. For example fw_activate was performed as a result
>> > + * of devlink reload triggered fw_activate on another host.
>> > + * The motivation for this function is to keep data on reload actions performed on this
>> > + * function whether it was done due to direct devlink reload call or not.
>> > + *
>> > + * @devlink: devlink
>> > + * @limit_level: reload action limit level
>> > + * @actions_performed: bitmask of actions performed
>> > + */
>> > +void devlink_reload_implicit_actions_performed(struct devlink *devlink,
>> > + enum devlink_reload_action_limit_level limit_level,
>> > + unsigned long actions_performed)
>> What I'm a bit scarred of that the driver would call this from withing
>> reload_down()/up() ops. Perheps this could be WARN_ON'ed here (or in
>> devlink_reload())?
>>
>
>Not sure how I know if it was called from devlink_reload_down()/up() ? Maybe
>mutex ? So the warn will be actually mutex deadlock ?
No. Don't abuse mutex for this.
Just make sure that the counters do not move when you call
reload_down/up().
>
>> > +{
>> > + if (!devlink_reload_supported(devlink))
>> Hmm. I think that the driver does not have to support the reload and can
>> still be reloaded by another instance and update the stats here. Why
>> not?
>>
>
>But I show counters only for supported reload actions and levels, otherwise
>we will have these counters on devlink dev show output for other drivers that
>don't have support for devlink reload and didn't implement any of these
>including this function and these drivers may do some actions like
>fw_activate in another way and don't update the stats and so that will make
>these stats misleading. They will show history "stats" but they don't update
>them as they didn't apply anything related to devlink reload.
The case I tried to point at is the driver instance, that does not
implement reload ops itself, but still it can be reloaded by someone else -
the other driver instance outside.
The counters should work no matter if the driver implements reload ops
or not. Why wouldn't they? The user still likes to know that the devices
was reloaded.
>
>> > + return;
>> > + devlink_reload_action_stats_update(devlink, limit_level, actions_performed);
>> > +}
>> > +EXPORT_SYMBOL_GPL(devlink_reload_implicit_actions_performed);
>> > +
>> > static int devlink_reload(struct devlink *devlink, struct net *dest_net,
>> > enum devlink_reload_action action,
>> > enum devlink_reload_action_limit_level limit_level,
>> > - struct netlink_ext_ack *extack, unsigned long *actions_performed)
>> > + struct netlink_ext_ack *extack, unsigned long *actions_performed_out)
>> > {
>> > + unsigned long actions_performed;
>> > int err;
>> >
>> > if (!devlink->reload_enabled)
>> > @@ -2998,9 +3045,14 @@ static int devlink_reload(struct devlink *devlink, struct net *dest_net,
>> > if (dest_net && !net_eq(dest_net, devlink_net(devlink)))
>> > devlink_reload_netns_change(devlink, dest_net);
>> >
>> > - err = devlink->ops->reload_up(devlink, action, limit_level, extack, actions_performed);
>> > + err = devlink->ops->reload_up(devlink, action, limit_level, extack, &actions_performed);
>> > devlink_reload_failed_set(devlink, !!err);
>> > - return err;
>> > + if (err)
>> > + return err;
>> > + devlink_reload_action_stats_update(devlink, limit_level, actions_performed);
>> > + if (actions_performed_out)
>> Just make the caller to provide valid pointer, as I suggested in the
>> other patch review.
>
>
>Ack.
>
>>
>> > + *actions_performed_out = actions_performed;
>> > + return 0;
>> > }
>> >
>> > static int
>> > --
>> > 2.17.1
>> >
next prev parent reply other threads:[~2020-09-16 0:33 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-14 6:07 [PATCH net-next RFC v4 00/15] Add devlink reload action and Moshe Shemesh
2020-09-14 6:07 ` [PATCH net-next RFC v4 01/15] devlink: Add reload action option to devlink reload command Moshe Shemesh
2020-09-14 7:08 ` Vasundhara Volam
2020-09-14 9:32 ` Jiri Pirko
2020-09-14 9:54 ` Vasundhara Volam
2020-09-14 11:28 ` Jiri Pirko
2020-09-14 21:31 ` Jakub Kicinski
2020-09-14 22:06 ` Michael Chan
2020-09-15 6:18 ` Jiri Pirko
2020-09-14 12:27 ` Jiri Pirko
2020-09-15 12:12 ` Moshe Shemesh
2020-09-15 13:26 ` Jiri Pirko
2020-09-15 20:06 ` Moshe Shemesh
2020-09-14 21:33 ` Jakub Kicinski
2020-09-15 12:56 ` Moshe Shemesh
2020-09-15 13:26 ` Jiri Pirko
2020-09-15 16:00 ` Jakub Kicinski
2020-09-14 6:07 ` [PATCH net-next RFC v4 02/15] devlink: Add reload action limit level Moshe Shemesh
2020-09-14 13:10 ` Jiri Pirko
2020-09-15 12:15 ` Moshe Shemesh
2020-09-14 6:07 ` [PATCH net-next RFC v4 03/15] devlink: Add reload action stats Moshe Shemesh
2020-09-14 13:39 ` Jiri Pirko
2020-09-15 12:30 ` Moshe Shemesh
2020-09-15 13:33 ` Jiri Pirko [this message]
2020-09-15 20:20 ` Moshe Shemesh
2020-09-16 6:07 ` Jiri Pirko
2020-09-14 6:07 ` [PATCH net-next RFC v4 04/15] devlink: Add reload actions stats to dev get Moshe Shemesh
2020-09-14 13:45 ` Jiri Pirko
2020-09-15 6:45 ` Ido Schimmel
2020-09-15 7:44 ` Jiri Pirko
2020-09-15 12:31 ` Moshe Shemesh
2020-09-15 13:34 ` Jiri Pirko
2020-09-15 20:33 ` Moshe Shemesh
2020-09-18 16:13 ` Moshe Shemesh
2020-09-21 10:33 ` Jiri Pirko
2020-09-14 6:07 ` [PATCH net-next RFC v4 05/15] net/mlx5: Add functions to set/query MFRL register Moshe Shemesh
2020-09-14 6:07 ` [PATCH net-next RFC v4 06/15] net/mlx5: Set cap for pci sync for fw update event Moshe Shemesh
2020-09-14 6:07 ` [PATCH net-next RFC v4 07/15] net/mlx5: Handle sync reset request event Moshe Shemesh
2020-09-14 6:07 ` [PATCH net-next RFC v4 08/15] net/mlx5: Handle sync reset now event Moshe Shemesh
2020-09-14 6:07 ` [PATCH net-next RFC v4 09/15] net/mlx5: Handle sync reset abort event Moshe Shemesh
2020-09-14 6:07 ` [PATCH net-next RFC v4 10/15] net/mlx5: Add support for devlink reload action fw activate Moshe Shemesh
2020-09-14 13:52 ` Jiri Pirko
2020-09-15 12:38 ` Moshe Shemesh
2020-09-14 13:54 ` Jiri Pirko
2020-09-15 12:44 ` Moshe Shemesh
2020-09-15 13:37 ` Jiri Pirko
2020-09-15 20:28 ` Moshe Shemesh
2020-09-16 6:08 ` Jiri Pirko
2020-09-14 6:07 ` [PATCH net-next RFC v4 11/15] devlink: Add enable_remote_dev_reset generic parameter Moshe Shemesh
2020-09-14 14:12 ` Jiri Pirko
2020-09-14 6:07 ` [PATCH net-next RFC v4 12/15] net/mlx5: Add devlink param enable_remote_dev_reset support Moshe Shemesh
2020-09-14 6:08 ` [PATCH net-next RFC v4 13/15] net/mlx5: Add support for fw live patch event Moshe Shemesh
2020-09-14 6:08 ` [PATCH net-next RFC v4 14/15] net/mlx5: Add support for devlink reload action limit level no reset Moshe Shemesh
2020-09-14 6:08 ` [PATCH net-next RFC v4 15/15] devlink: Add Documentation/networking/devlink/devlink-reload.rst Moshe Shemesh
2020-09-14 11:43 ` Jiri Pirko
2020-09-15 16:04 ` Jakub Kicinski
2020-09-15 19:59 ` Moshe Shemesh
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=20200915133309.GP2236@nanopsycho.orion \
--to=jiri@resnulli.us \
--cc=davem@davemloft.net \
--cc=jiri@mellanox.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=moshe@mellanox.com \
--cc=moshe@nvidia.com \
--cc=netdev@vger.kernel.org \
/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.