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 C15A3C433F5 for ; Thu, 10 Mar 2022 08:57:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236992AbiCJI6Z (ORCPT ); Thu, 10 Mar 2022 03:58:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231532AbiCJI6X (ORCPT ); Thu, 10 Mar 2022 03:58:23 -0500 Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B247137584 for ; Thu, 10 Mar 2022 00:57:19 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id D1F845C0231; Thu, 10 Mar 2022 03:57:16 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 10 Mar 2022 03:57:16 -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=ka/E0eAdPC7UgSU8h qJrl5IOAEJ3kI6QMbxuYq3n7oY=; b=fkGHUSBW+1BKExsLniVgi2ulmFHeCzJMR VAz8ztNhh8AWvxfNoCkA0sEL41wi18MySLEU7LQxNrHbMbcLH5e5ZaOvE6hkEvAM cVtcLLNSOP2VrkXoTUiFrDYd1JXAFkjEZQ+sgqxHkvwkikwgAuzif9tqNseyvRVI x8TdmVPAJlGHzf9jAdob+9RDIesMGKXR1ihrqjnniljjws4eb4FWxRwFn+Kubgy9 vZMNwGj8XFSfCpGXJ423Ag5v5yFsyscK+8Ij270EzSRebaPY1Jfy5HScROIKch7c GArdVag3yqxlco71vSJz/lfk8V7TD/01ckPDjl2vmUG38+rmO1e5A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudduledguddviecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehttd ertddttddvnecuhfhrohhmpefkughoucfutghhihhmmhgvlhcuoehiughoshgthhesihgu ohhstghhrdhorhhgqeenucggtffrrghtthgvrhhnpedtffekkeefudffveegueejffejhf etgfeuuefgvedtieehudeuueekhfduheelteenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehiughoshgthhesihguohhstghhrdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 10 Mar 2022 03:57:15 -0500 (EST) Date: Thu, 10 Mar 2022 10:57:12 +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: <20220310001632.470337-1-kuba@kernel.org> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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