All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leonro@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: <idosch@nvidia.com>, <petrm@nvidia.com>,
	<simon.horman@corigine.com>, <netdev@vger.kernel.org>,
	<jiri@resnulli.us>
Subject: Re: [RFT net-next 0/6] devlink: expose instance locking and simplify port splitting
Date: Fri, 11 Mar 2022 08:30:20 +0200	[thread overview]
Message-ID: <YirsfJF/T13qsVSu@unreal> (raw)
In-Reply-To: <20220310121348.35d8fc41@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Thu, Mar 10, 2022 at 12:13:48PM -0800, Jakub Kicinski wrote:
> On Thu, 10 Mar 2022 11:07:14 +0200 Leon Romanovsky 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 pursuing in cleanup this devlink mess.
> > 
> > Do you plan to send a series that removes devlink_mutex?
> 
> I would like to convert enough to explicit locking to allow simpler
> reload handling. I'm happy to leave devlink_mutex removal to someone
> else, but if there are no takers will do it as well. Let's see how 
> it goes.

Alright, let's see.

The main obstacle to remove devlink_mutex was netdevsim port creation sysfs,
so after your locking series, that change will be more or less trivial.

Thanks

  reply	other threads:[~2022-03-11  6:30 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-10  0:16 [RFT net-next 0/6] devlink: expose instance locking and simplify port splitting Jakub Kicinski
2022-03-10  0:16 ` [RFT net-next 1/6] devlink: expose instance locking and add locked port registering Jakub Kicinski
2022-03-10  9:14   ` Jiri Pirko
2022-03-10 20:06     ` Jakub Kicinski
2022-03-11  9:15       ` Jiri Pirko
2022-03-11 16:33         ` Jakub Kicinski
2022-03-14 12:43           ` Jiri Pirko
2022-03-11 16:09   ` Leon Romanovsky
2022-03-11 16:26     ` Jakub Kicinski
2022-03-11 16:57       ` Leon Romanovsky
2022-03-11 17:39         ` Jakub Kicinski
2022-03-11 17:41           ` Jakub Kicinski
2022-03-11 17:49           ` Leon Romanovsky
2022-03-11 18:06             ` Jakub Kicinski
2022-03-11 18:19               ` Leon Romanovsky
2022-03-10  0:16 ` [RFT net-next 2/6] eth: nfp: wrap locking assertions in helpers Jakub Kicinski
2022-03-10  0:16 ` [RFT net-next 3/6] eth: nfp: replace driver's "pf" lock with devlink instance lock Jakub Kicinski
2022-03-10  0:16 ` [RFT net-next 4/6] eth: mlxsw: switch to explicit locking for port registration Jakub Kicinski
2022-03-10  9:17   ` Jiri Pirko
2022-03-10 20:08     ` Jakub Kicinski
2022-03-10  0:16 ` [RFT net-next 5/6] devlink: hold the instance lock in port_split / port_unsplit callbacks Jakub Kicinski
2022-03-10  0:16 ` [RFT net-next 6/6] devlink: pass devlink_port to " Jakub Kicinski
2022-03-10  8:57 ` [RFT net-next 0/6] devlink: expose instance locking and simplify port splitting Ido Schimmel
2022-03-10 21:13   ` Ido Schimmel
2022-03-10 21:28     ` Jakub Kicinski
2022-03-14 18:46     ` Jakub Kicinski
2022-03-14 19:10       ` Ido Schimmel
2022-03-14 20:11         ` Jakub Kicinski
2022-03-15  7:39       ` Leon Romanovsky
2022-03-15 15:58         ` Jakub Kicinski
2022-03-15 17:54           ` Leon Romanovsky
2022-03-10  9:05 ` Jiri Pirko
2022-03-10  9:07 ` Leon Romanovsky
2022-03-10 20:13   ` Jakub Kicinski
2022-03-11  6:30     ` Leon Romanovsky [this message]
2022-03-11 10:48 ` Simon Horman
2022-03-11 16:34   ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YirsfJF/T13qsVSu@unreal \
    --to=leonro@nvidia.com \
    --cc=idosch@nvidia.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=petrm@nvidia.com \
    --cc=simon.horman@corigine.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.