Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp53130pxk; Tue, 15 Sep 2020 17:33:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyMMa9ZnFmt7lVe4VrwR8lAKdRHIa0ae5RG+2cGjhmaH5CeKFzP7jcKCkY3Z0oUT5N8vDAD X-Received: by 2002:a17:906:2354:: with SMTP id m20mr22137190eja.341.1600216427896; Tue, 15 Sep 2020 17:33:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600216427; cv=none; d=google.com; s=arc-20160816; b=YK/NIEWmyUENybDotUcqQ/IwfCI1M2qChvho9n56QqqTQpBBPTiIDYLVdCH7D3Rg9s toKJCdDqF6swnMvl07wmnL+isu9QpuEdm99uU29eaO+tppeYcQUd9+/iM/+IerEEGq7B NGHN7kPCb4Gh9PgpK+8Ig04kbnPtqUsfG85ApohdeERZIyQ5/6cVyfQD3/4rN09Gjfj1 1V/ZgCSKJA+z/voaAh7vJBF+oSGs1GVOKpbs5ORkm0M+7ObLEKIPvJsPdIZJ+eu/GOoR 6aAdf16Qukinuv7oR0Do+Hi6Bb8NWOzgn64jdS7LI3hMbn2xmljqRxK07VZRzcPvwnHQ mkeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=hzZUY6CzToqBP67sQ2Eg3vFtmd/tMofW6+beTEUER7c=; b=mwiwRgG0gQY+pt+xjiiGDdafbPiMKiRPq3npjLPQNFpb6qDpO8I6yvOuZVDkApwIoJ 6VPDhOoLIDSqsEMdOVidKSPcEcRv0x7JIlKFvuOTAwn0l9fqpXLL02bq5F+VXsf3nIxN CrfHbdWeC2p1upcwyfruFoJ7I6Kpsu17lmQ4P/3iROv6ZT+vE5Bm1mvAMOKYRns36e6H gQio14Cpi8YUCgsiznDL9/+cuK+3EG9ZvOGlKnf0rj1J4vRnODLVwb/6G3sXG+rojZqh E/Fmp5b2nNm0siMbp/E2IlH8I10GY9Psce0H5hifxtb2ZwCG1rJc9UX/PZf9E3GFAgGQ idYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@resnulli-us.20150623.gappssmtp.com header.s=20150623 header.b=ApkNpCci; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cf25si10820780ejb.67.2020.09.15.17.33.24; Tue, 15 Sep 2020 17:33:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@resnulli-us.20150623.gappssmtp.com header.s=20150623 header.b=ApkNpCci; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727231AbgIPAct (ORCPT + 99 others); Tue, 15 Sep 2020 20:32:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55264 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726693AbgIONnK (ORCPT ); Tue, 15 Sep 2020 09:43:10 -0400 Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C284C0611C1 for ; Tue, 15 Sep 2020 06:33:12 -0700 (PDT) Received: by mail-wm1-x341.google.com with SMTP id d4so3381917wmd.5 for ; Tue, 15 Sep 2020 06:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=hzZUY6CzToqBP67sQ2Eg3vFtmd/tMofW6+beTEUER7c=; b=ApkNpCciOAKKyfaftQveS7q+/ZQq6pyHPB7v7pNLGKIZR74KS+b1NJjOPyNRK9+Lwl QsopcajViP1UTRhKo5wdkv7k0rmkMAcqExdskjTq0CAv32qka0Yi3v8JFlLWT+NI02UB dpUmvJLlDbS8W4Uh67iuQxWP7xOzRvAQ61t6dIMwslJ4QshFQWyMzPgGnoENMS4mTdrb wTmL4jMZ4uz3nMLOd22ZXNmjmvYi8wszy5VrAttSHn39fdGqeJg1apZN7hZKys8C18O5 jvOYRZWKKgtWEyeffn3L5WAtJZ/ENM99O6cuWPP3k4zlakhGJ6UUY09aDLCbSygEjqtL a6Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=hzZUY6CzToqBP67sQ2Eg3vFtmd/tMofW6+beTEUER7c=; b=I1stJvwZqaPAVYdsAfUDKWvQs/L9PWla1m4WeviaN2sJBBpRdSSgvOgruPMoCxdLsf byl1ScWYJeuCU6E7cxD+QBAowyKvSky5+ZPAJqEVSXL6911azN1Bk9VwnpDIycvTfCfG znPP5oT95OkjUraM2u9d+GR7t5Oxzm/8xSY+Kk+W4bNLF9Lbu2fclj2LQGA/dP7ZBHJM UDjYrHMyKBp7UMdGOVUYyAMjXzFYfOpZSv4I6ojGr7xiShPpgqza4wIc9OqZoxmqlNug SmoLpV0RTNR2M0LyviZl3PDrEnnbtYgPKaeP0ADF8dzx3mQp9CyKtRFnYlg4TdrB1WVf 6lXA== X-Gm-Message-State: AOAM533jo6vlVHIV3y2w+/Wsl57BknlS8ojcC2hVubgpzql2AWESAD9B 2uE1/bVUo9Dxp4iHFEq9xwqwfA== X-Received: by 2002:a1c:e0d4:: with SMTP id x203mr5113109wmg.91.1600176790703; Tue, 15 Sep 2020 06:33:10 -0700 (PDT) Received: from localhost ([86.61.181.4]) by smtp.gmail.com with ESMTPSA id a11sm23856074wmm.18.2020.09.15.06.33.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2020 06:33:10 -0700 (PDT) Date: Tue, 15 Sep 2020 15:33:09 +0200 From: Jiri Pirko To: Moshe Shemesh Cc: Moshe Shemesh , "David S. Miller" , Jakub Kicinski , Jiri Pirko , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next RFC v4 03/15] devlink: Add reload action stats Message-ID: <20200915133309.GP2236@nanopsycho.orion> References: <1600063682-17313-1-git-send-email-moshe@mellanox.com> <1600063682-17313-4-git-send-email-moshe@mellanox.com> <20200914133939.GG2236@nanopsycho.orion> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >> >