All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@idosch.org>
To: Jakub Kicinski <kuba@kernel.org>
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
Date: Thu, 10 Mar 2022 23:13:02 +0200	[thread overview]
Message-ID: <Yipp3sQewk9y0RVP@shredder> (raw)
In-Reply-To: <Yim9aIeF8oHG59tG@shredder>

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/

  reply	other threads:[~2022-03-10 21:13 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 [this message]
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
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=Yipp3sQewk9y0RVP@shredder \
    --to=idosch@idosch.org \
    --cc=idosch@nvidia.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=leonro@nvidia.com \
    --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.