netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Cc: netdev@vger.kernel.org, "David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Shannon Nelson <shannon.nelson@amd.com>,
	Michael Chan <michael.chan@broadcom.com>,
	Edwin Peer <edwin.peer@broadcom.com>,
	Cai Huoqing <cai.huoqing@linux.dev>, Luo bin <luobin9@huawei.com>,
	George Cherian <george.cherian@marvell.com>,
	Danielle Ratson <danieller@nvidia.com>,
	Moshe Shemesh <moshe@nvidia.com>,
	Saeed Mahameed <saeedm@nvidia.com>,
	Brett Creeley <brett.creeley@amd.com>,
	Vasundhara Volam <vasundhara-v.volam@broadcom.com>,
	Sunil Goutham <sgoutham@marvell.com>,
	Linu Cherian <lcherian@marvell.com>,
	Geetha sowjanya <gakula@marvell.com>,
	Jerin Jacob <jerinj@marvell.com>, hariprasad <hkelam@marvell.com>,
	Subbaraya Sundeep <sbhatta@marvell.com>,
	Ido Schimmel <idosch@nvidia.com>, Petr Machata <petrm@nvidia.com>,
	Eran Ben Elisha <eranbe@nvidia.com>,
	Aya Levin <ayal@mellanox.com>, Leon Romanovsky <leon@kernel.org>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>
Subject: Re: [PATCH net-next v1 1/8] devlink: retain error in struct devlink_fmsg
Date: Tue, 10 Oct 2023 13:34:20 +0200	[thread overview]
Message-ID: <ZSU2vH/As7RIcH7W@nanopsycho> (raw)
In-Reply-To: <20231010104318.3571791-2-przemyslaw.kitszel@intel.com>

Tue, Oct 10, 2023 at 12:43:11PM CEST, przemyslaw.kitszel@intel.com wrote:
>Retain error value in struct devlink_fmsg, to relieve drivers from
>checking it after each call.
>Note that fmsg is an in-memory builder/buffer of formatted message,
>so it's not the case that half baked message was sent somewhere.
>
>We could find following scheme in multiple drivers:
>  err = devlink_fmsg_obj_nest_start(fmsg);
>  if (err)
>  	return err;
>  err = devlink_fmsg_string_pair_put(fmsg, "src", src);
>  if (err)
>  	return err;
>  err = devlink_fmsg_something(fmsg, foo, bar);
>  if (err)
>	return err;
>  // and so on...
>  err = devlink_fmsg_obj_nest_end(fmsg);
>
>With retaining error API that translates to:
>  devlink_fmsg_obj_nest_start(fmsg);
>  devlink_fmsg_string_pair_put(fmsg, "src", src);
>  devlink_fmsg_something(fmsg, foo, bar);
>  // and so on...
>  err = devlink_fmsg_obj_nest_end(fmsg);

I like this approach. But it looks a bit odd that you store error and
return it as well, leaving the caller to decide what to do in his code.
It is not desirable to leave the caller wondering.

Also, it is customary to check the return value if the function returns
it. This approach confuses the customs.

Also, eventually, the fmsg is getting send. That is the point where the
error could be checked and handled properly, for example by filling nice
extack message.

What I'm saying is, please convert them all to return void, store the
error and check that before fmsg send. That makes the approach unified
for all callers, code nicer. Even the custom in-driver put functions
would return void. The callbacks (e. g. dump) would also return void.

+ a small nit below:


>
>What means we check error just at the end
>(one could return it directly of course).
>
>Possible error scenarios are developer error (API misuse) and memory
>exhaustion, both cases are good candidates to choose readability
>over fastest possible exit.
>
>This commit itself is an illustration of benefits for the dev-user,
>more of it will be in separate commits of the series.
>
>Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
>Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
>---
>add/remove: 2/4 grow/shrink: 11/9 up/down: 325/-646 (-321)
>---
> net/devlink/health.c | 255 ++++++++++++++++---------------------------
> 1 file changed, 92 insertions(+), 163 deletions(-)
>
>diff --git a/net/devlink/health.c b/net/devlink/health.c
>index 638cad8d5c65..2d26479e9dbe 100644
>--- a/net/devlink/health.c
>+++ b/net/devlink/health.c
>@@ -19,6 +19,7 @@ struct devlink_fmsg_item {
> 
> struct devlink_fmsg {
> 	struct list_head item_list;
>+	int err; /* first error encountered on some devlink_fmsg_XXX() call */
> 	bool putting_binary; /* This flag forces enclosing of binary data
> 			      * in an array brackets. It forces using
> 			      * of designated API:
>@@ -565,10 +566,8 @@ static int devlink_health_do_dump(struct devlink_health_reporter *reporter,
> 		return 0;
> 
> 	reporter->dump_fmsg = devlink_fmsg_alloc();
>-	if (!reporter->dump_fmsg) {
>-		err = -ENOMEM;
>-		return err;
>-	}
>+	if (!reporter->dump_fmsg)
>+		return -ENOMEM;
> 
> 	err = devlink_fmsg_obj_nest_start(reporter->dump_fmsg);
> 	if (err)
>@@ -673,43 +672,59 @@ int devlink_nl_cmd_health_reporter_recover_doit(struct sk_buff *skb,
> 	return devlink_health_reporter_recover(reporter, NULL, info->extack);
> }
> 
>-static int devlink_fmsg_nest_common(struct devlink_fmsg *fmsg,
>-				    int attrtype)
>+static bool _devlink_fmsg_err_or_binary(struct devlink_fmsg *fmsg)

No need for "_" here. Drop it.


>+{
>+	if (!fmsg->err && fmsg->putting_binary)
>+		fmsg->err = -EINVAL;
>+
>+	return fmsg->err;
>+}
>+

[...]

  reply	other threads:[~2023-10-10 11:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-10 10:43 [PATCH net-next v1 0/8] devlink: retain error in struct devlink_fmsg Przemek Kitszel
2023-10-10 10:43 ` [PATCH net-next v1 1/8] " Przemek Kitszel
2023-10-10 11:34   ` Jiri Pirko [this message]
2023-10-10 13:36     ` Przemek Kitszel
2023-10-10 14:03       ` Jiri Pirko
2023-10-10 10:43 ` [PATCH net-next v1 2/8] netdevsim: devlink health: use retained error fmsg API Przemek Kitszel
2023-10-10 10:43 ` [PATCH net-next v1 3/8] pds_core: " Przemek Kitszel
2023-10-10 16:53   ` Nelson, Shannon
2023-10-12 11:30     ` Przemek Kitszel
2023-10-10 10:43 ` [PATCH net-next v1 4/8] bnxt_en: " Przemek Kitszel
2023-10-12 11:34   ` Przemek Kitszel
2023-10-10 10:43 ` [PATCH net-next v1 5/8] hinic: " Przemek Kitszel
2023-10-10 10:43 ` [PATCH net-next v1 6/8] octeontx2-af: " Przemek Kitszel
2023-10-10 10:43 ` [PATCH net-next v1 7/8] mlxsw: core: " Przemek Kitszel
2023-10-10 10:43 ` [PATCH net-next v1 8/8] net/mlx5: " Przemek Kitszel

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=ZSU2vH/As7RIcH7W@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=ayal@mellanox.com \
    --cc=brett.creeley@amd.com \
    --cc=cai.huoqing@linux.dev \
    --cc=danieller@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=edwin.peer@broadcom.com \
    --cc=eranbe@nvidia.com \
    --cc=gakula@marvell.com \
    --cc=george.cherian@marvell.com \
    --cc=hkelam@marvell.com \
    --cc=idosch@nvidia.com \
    --cc=jerinj@marvell.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=kuba@kernel.org \
    --cc=lcherian@marvell.com \
    --cc=leon@kernel.org \
    --cc=luobin9@huawei.com \
    --cc=michael.chan@broadcom.com \
    --cc=moshe@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=petrm@nvidia.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=saeedm@nvidia.com \
    --cc=sbhatta@marvell.com \
    --cc=sgoutham@marvell.com \
    --cc=shannon.nelson@amd.com \
    --cc=vasundhara-v.volam@broadcom.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).