From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90B58C433F5 for ; Thu, 10 Mar 2022 21:13:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343889AbiCJVON (ORCPT ); Thu, 10 Mar 2022 16:14:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50538 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343905AbiCJVOM (ORCPT ); Thu, 10 Mar 2022 16:14:12 -0500 Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 250D1CFB98 for ; Thu, 10 Mar 2022 13:13:10 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 63CA93201805; Thu, 10 Mar 2022 16:13:07 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 10 Mar 2022 16:13:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=d0hfR+3vqD+pUfTks VBh7MPDay0SYutkoW9FR+/myak=; b=P4FxgZD3vK9dza8aexeV4anjiJTDbkQIM Gx1zOpQE5VbLBuG7Uz8rO0JDfnvbROq2Ucl5QTK3mvKTJvJvaTrPHJOeHB5jlYXj dwnMKFMzLh6D2aiS0W+HyshbAqlOlMnweadVZoFGnV0enpEPtH9OeHc0hlBS+VgH jtvJnf6wOgbGtXsebKSmclVsAQj2K4tRfP6/K8gCs+2ESMYG6VpZUxsQI/49LT2R p5gScCV80CumWnICGoRtXs3DaMCd35Ek4WufcmVdqP9xl/xKXmGnrfpOsa7DFIfM iCqU7aHTBpCZtSGif00st4PM8hh0al6Ai4mDkNbJ+rNv4v4SDh/TA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddvtddgudegjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehttd ertddttddvnecuhfhrohhmpefkughoucfutghhihhmmhgvlhcuoehiughoshgthhesihgu ohhstghhrdhorhhgqeenucggtffrrghtthgvrhhnpefgvefgveeuudeuffeiffehieffgf ejleevtdetueetueffkeevgffgtddugfekveenucffohhmrghinhepkhgvrhhnvghlrdho rhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepih guohhstghhsehiughoshgthhdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 10 Mar 2022 16:13:05 -0500 (EST) Date: Thu, 10 Mar 2022 23:13:02 +0200 From: Ido Schimmel To: Jakub Kicinski Cc: idosch@nvidia.com, petrm@nvidia.com, simon.horman@corigine.com, netdev@vger.kernel.org, leonro@nvidia.com, jiri@resnulli.us Subject: Re: [RFT net-next 0/6] devlink: expose instance locking and simplify port splitting Message-ID: References: <20220310001632.470337-1-kuba@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Mar 10, 2022 at 10:57:17AM +0200, Ido Schimmel wrote: > On Wed, Mar 09, 2022 at 04:16:26PM -0800, Jakub Kicinski wrote: > > This series puts the devlink ports fully under the devlink instance > > lock's protection. As discussed in the past it implements my preferred > > solution of exposing the instance lock to the drivers. This way drivers > > which want to support port splitting can lock the devlink instance > > themselves on the probe path, and we can take that lock in the core > > on the split/unsplit paths. > > > > nfp and mlxsw are converted, with slightly deeper changes done in > > nfp since I'm more familiar with that driver. > > > > Now that the devlink port is protected we can pass a pointer to > > the drivers, instead of passing a port index and forcing the drivers > > to do their own lookups. Both nfp and mlxsw can container_of() to > > their own structures. > > > > I'd appreciate some testing, I don't have access to this HW. > > Thanks for working on this. I ran a few tests that exercise these code > paths with a debug config and did not see any immediate problems. I will > go over the patches later today Went over the patches and they look good to me. Thanks again. Will run a full regression with them on Sunday. I read [1] and [2] again to refresh my memory about this conversion. Can you provide a rough outline of how you plan to go about it? Asking so that I will know what to expect and how it all fits together. I expect that eventually 'DEVLINK_NL_FLAG_NO_LOCK' will be removed from 'DEVLINK_CMD_RELOAD' and then the devl_lock()/devl_unlock() that you left in drivers will be moved to earlier in the probe path so that we don't deadlock on reload. [1] https://lore.kernel.org/lkml/YYgJ1bnECwUWvNqD@shredder/ [2] https://lore.kernel.org/netdev/20211030231254.2477599-1-kuba@kernel.org/