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;
From:   "Keller, Jacob E" <jacob.e.keller@intel.com>
To:     Jakub Kicinski <kuba@kernel.org>, Leon Romanovsky <leon@kernel.org>
CC:     "David S . Miller" <davem@davemloft.net>,
        Guangbin Huang <huangguangbin2@huawei.com>,
        Jiri Pirko <jiri@nvidia.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        Salil Mehta <salil.mehta@huawei.com>,
        Shannon Nelson <snelson@pensando.io>,
        Yisen Zhuang <yisen.zhuang@huawei.com>,
        Yufeng Mo <moyufeng@huawei.com>
Subject: RE: [PATCH net-next 3/6] devlink: Count struct devlink consumers
Thread-Topic: [PATCH net-next 3/6] devlink: Count struct devlink consumers
Thread-Index: AQHXkPLeq0W5yofhY0KH8k2ic9V3+Kt2SjGAgAABsoCAAAO0AIAAWqrw
Date:   Mon, 16 Aug 2021 21:32:17 +0000
Message-ID: <CO1PR11MB50895F0BA3FE20CD92D79CB6D6FD9@CO1PR11MB5089.namprd11.prod.outlook.com>
References: <cover.1628933864.git.leonro@nvidia.com>
        <d4d59d801f4521e562c9ecf2d8767077aaefb456.1628933864.git.leonro@nvidia.com>
        <20210816084741.1dd1c415@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
        <YRqKCVbjTZaSrSy+@unreal>
 <20210816090700.313a54ba@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
In-Reply-To: <20210816090700.313a54ba@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-reaction: no-action
dlp-version: 11.5.1.3
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?ogDrB43eYj8jpWODBHgyyTFjStCTvut1ho6FwVembN4ifZsymIpSItTqNOw/?=
 =?us-ascii?Q?t3ovInmeW9l6hxUtfLpX1txO/cycEp0DrYJP3SgZwYAde2AMD6RlIpc+Utoz?=
 =?us-ascii?Q?ulsVV7G6TLlrfhbe9i6IqrNl43Sm4aTesZ4AaMmAfsFAap5bqdA2FsNEdTVK?=
 =?us-ascii?Q?mstbViRjPimq1qVfA10/6O3YeSqtqrgJRAHNxSYkL6A8pfcGi3eDQyUxch9J?=
 =?us-ascii?Q?AaehFf5LMnVeP2jwPv1prqCrsL1rpDwN5zQDMMKRkiGbPwZO28bxa2puQZm/?=
 =?us-ascii?Q?vw/GRywCl72xGqlPqxtea45FWm4VrpVPHR42GotCbuE3cfrcqmlueGYfkkmd?=
 =?us-ascii?Q?rGQxNwy7GfZLPpuQ9rUgLbXRPInLJ/Ywqz7MFj5fiIylSt3D7uCcZHJdd931?=
 =?us-ascii?Q?BDjF19PEvLBX2PNpGSIkt6/6S2Qrv+ECARmG3zoYnNJ67qdbe1u9l9kH3Qd0?=
 =?us-ascii?Q?TPlJrXqOfabZq8r4QbleANwx1FVZ6yQSbaIqW0QvoTKdejmqZZUFX9a+jBWX?=
 =?us-ascii?Q?Yp7cCX3OmsDhYs1bkAy5pZueox3JycjBI3RVYuoXFwosyRGIfaZ/RZUzgX7K?=
 =?us-ascii?Q?2p2OQabzwzLryEBGeA0+XmXHT7dydLRGhtH/Yune665L6l6oEzC16/nIbT9c?=
 =?us-ascii?Q?TLuX5wjW7/pCIMT6Dkwot2cpiyeje0NlbYr/URbdoHFUsjk8fa0pvifhzwCq?=
 =?us-ascii?Q?pCdnh2uNJ9oj2HtjY+c9w8nKjF6XLzessQp4GGKO/C9KGNYKTAXn09bhmc6e?=
 =?us-ascii?Q?onX0N/9Mjqp5I4SDakiuyrT5fBJKjVb96EMj7ATWNVov1Hj9xGDaNbflxNlA?=
 =?us-ascii?Q?YGHUxS0GZf2Pbhr4dIF0tzHp7RRFg8uYMPlhw1vVBUEynBz8ziDK7nZvFfCm?=
 =?us-ascii?Q?t9OArd+Kk3bC9Appb8DdgwYaXbxGR6QONK7ZzqA2bL9WU1GWxVZWjpaOLgib?=
 =?us-ascii?Q?5st8a5mFfE4pStMQTcsep0dgi5nw15A4qZoW7E8E0LLXfnXRrnIfBbQz2o7X?=
 =?us-ascii?Q?3+ZzxhFLmu+2yG6qgoNs1QnokLYiiGTJnibP0Us4Q2anjjYLqYECBRXJn9Tk?=
 =?us-ascii?Q?obYmAeMcY5fZ1ew456Nue2LvDIDb4gHzswicvrhCU4IYx8H6toXvgZzMpz0Y?=
 =?us-ascii?Q?FnAx6FQDWnGVgE5x4bO5wMvERfjioPrnOCklpVV8Ux3vWtdMMop8tZA+EGIS?=
 =?us-ascii?Q?X/9XTAjS5S8A5k8EowWAPJXfXFAgtU7fsJcVV2r/Py5ujftn+ZQT6I2c9mkt?=
 =?us-ascii?Q?WrcUkx8eheI5JNjne58YjGpnDRi9rjlXB2lqyaQzIDSgmpba/ViqcDq26Mnd?=
 =?us-ascii?Q?SDc=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB5089.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9b25080d-e45a-4969-387e-08d960fd529f
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2021 21:32:17.7251
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yIGL7YtBdzlHE+Br9D7tPw4wSj+9JkK4pcmsS4CNWlaml6IQQRFDKw8dHP6AJ/Fe7VXp34e9FM2R+87PwFxpPrd7JAyCoRy7tcVyMQwOlnA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB0031
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> -----Original Message-----
> From: Jakub Kicinski <kuba@kernel.org>
> Sent: Monday, August 16, 2021 9:07 AM
> To: Leon Romanovsky <leon@kernel.org>
> Cc: David S . Miller <davem@davemloft.net>; Guangbin Huang
> <huangguangbin2@huawei.com>; Keller, Jacob E <jacob.e.keller@intel.com>; =
Jiri
> Pirko <jiri@nvidia.com>; linux-kernel@vger.kernel.org; netdev@vger.kernel=
.org;
> Salil Mehta <salil.mehta@huawei.com>; Shannon Nelson
> <snelson@pensando.io>; Yisen Zhuang <yisen.zhuang@huawei.com>; Yufeng
> Mo <moyufeng@huawei.com>
> Subject: Re: [PATCH net-next 3/6] devlink: Count struct devlink consumers
>=20
> On Mon, 16 Aug 2021 18:53:45 +0300 Leon Romanovsky wrote:
> > On Mon, Aug 16, 2021 at 08:47:41AM -0700, Jakub Kicinski wrote:
> > > On Sat, 14 Aug 2021 12:57:28 +0300 Leon Romanovsky wrote:
> > > > From: Leon Romanovsky <leonro@nvidia.com>
> > > >
> > > > The struct devlink itself is protected by internal lock and doesn't
> > > > need global lock during operation. That global lock is used to prot=
ect
> > > > addition/removal new devlink instances from the global list in use =
by
> > > > all devlink consumers in the system.
> > > >
> > > > The future conversion of linked list to be xarray will allow us to
> > > > actually delete that lock, but first we need to count all struct de=
vlink
> > > > users.
> > >
> > > Not a problem with this set but to state the obvious the global devli=
nk
> > > lock also protects from concurrent execution of all the ops which don=
't
> > > take the instance lock (DEVLINK_NL_FLAG_NO_LOCK). You most likely kno=
w
> > > this but I thought I'd comment on an off chance it helps.
> >
> > The end goal will be something like that:
> > 1. Delete devlink lock
> > 2. Rely on xa_lock() while grabbing devlink instance (past devlink_try_=
get)
> > 3. Convert devlink->lock to be read/write lock to make sure that we can=
 run
> > get query in parallel.
> > 4. Open devlink netlink to parallel ops, ".parallel_ops =3D true".
>=20
> IIUC that'd mean setting eswitch mode would hold write lock on
> the dl instance. What locks does e.g. registering a dl port take
> then?

Also that I think we have some cases where we want to allow the driver to a=
llocate new devlink objects in response to adding a port, but still want to=
 block other global operations from running?