Messages in this thread | | | Date | Wed, 18 Aug 2021 11:12:15 +0300 | From | Leon Romanovsky <> | Subject | Re: [PATCH net-next 3/6] devlink: Count struct devlink consumers |
| |
On Mon, Aug 16, 2021 at 09:32:17PM +0000, Keller, Jacob E wrote: > > > > -----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 > > > > 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 protect > > > > > 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 devlink > > > > > users. > > > > > > > > Not a problem with this set but to state the obvious the global devlink > > > > 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 know > > > > 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 = true". > > > > 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 allocate new devlink objects in response to adding a port, but still want to block other global operations from running?
I don't see the flow where operations on devlink_A should block devlink_B. Only in such flows we will need global lock like we have now - devlink->lock. In all other flows, write lock of devlink instance will protect from parallel execution.
Thanks
| |