From: Jakub Kicinski <kuba@kernel.org>
To: Jiri Pirko <jiri@resnulli.us>
Cc: netdev@vger.kernel.org, davem@davemloft.net, pabeni@redhat.com,
edumazet@google.com, tariqt@nvidia.com, moshe@nvidia.com,
saeedm@nvidia.com, linux-rdma@vger.kernel.org
Subject: Re: [patch net-next v2 00/13] net: fix netdev to devlink_port linkage and expose to user
Date: Mon, 3 Oct 2022 09:45:56 -0700 [thread overview]
Message-ID: <20221003094556.1f16a255@kernel.org> (raw)
In-Reply-To: <20221003105204.3315337-1-jiri@resnulli.us>
On Mon, 3 Oct 2022 12:51:51 +0200 Jiri Pirko wrote:
> Currently, the info about linkage from netdev to the related
> devlink_port instance is done using ndo_get_devlink_port().
> This is not sufficient, as it is up to the driver to implement it and
> some of them don't do that. Also it leads to a lot of unnecessary
> boilerplate code in all the drivers.
>
> Instead of that, introduce a possibility for driver to expose this
> relationship by new SET_NETDEV_DEVLINK_PORT macro which stores it into
> dev->devlink_port. It is ensured by the driver init/fini flows that
> the devlink_port pointer does not change during the netdev lifetime.
> Devlink port is always registered before netdev register and
> unregistered after netdev unregister.
>
> Benefit from this linkage setup and remove explicit calls from driver
> to devlink_port_type_eth_set() and clear(). Many of the driver
> didn't use it correctly anyway. Let the devlink.c to track associated
> netdev events and adjust type and type pointer accordingly. Also
> use this events to to keep track on ifname change and remove RTNL lock
> taking from devlink_nl_port_fill().
>
> Finally, remove the ndo_get_devlink_port() ndo which is no longer used
> and expose devlink_port handle as a new netdev netlink attribute to the
> user. That way, during the ifname->devlink_port lookup, userspace app
> does not have to dump whole devlink port list and instead it can just
> do a simple RTM_GETLINK query.
Would you be okay if we deferred until 6.2?
It's technically past the deadline and some odd driver could regress.
next prev parent reply other threads:[~2022-10-03 16:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-03 10:51 [patch net-next v2 00/13] net: fix netdev to devlink_port linkage and expose to user Jiri Pirko
2022-10-03 10:51 ` [patch net-next v2 01/13] net: devlink: convert devlink port type-specific pointers to union Jiri Pirko
2022-10-03 10:51 ` [patch net-next v2 02/13] net: devlink: move port_type_warn_schedule() call to __devlink_port_type_set() Jiri Pirko
2022-10-03 10:51 ` [patch net-next v2 03/13] net: devlink: move port_type_netdev_checks() " Jiri Pirko
2022-10-03 10:51 ` [patch net-next v2 04/13] net: devlink: take RTNL in port_fill() function only if it is not held Jiri Pirko
2022-10-03 10:51 ` [patch net-next v2 05/13] net: devlink: track netdev with devlink_port assigned Jiri Pirko
2022-10-03 10:51 ` [patch net-next v2 06/13] net: make drivers to use SET_NETDEV_DEVLINK_PORT to set devlink_port Jiri Pirko
2022-10-03 16:46 ` Jakub Kicinski
2022-10-03 10:51 ` [patch net-next v2 07/13] net: devlink: remove netdev arg from devlink_port_type_eth_set() Jiri Pirko
2022-10-03 10:51 ` [patch net-next v2 08/13] net: devlink: remove net namespace check from devlink_nl_port_fill() Jiri Pirko
2022-10-03 10:52 ` [patch net-next v2 09/13] net: devlink: store copy netdevice ifindex and ifname to allow port_fill() without RTNL held Jiri Pirko
2022-10-03 10:52 ` [patch net-next v2 10/13] net: devlink: add not cleared type warning to port unregister Jiri Pirko
2022-10-03 10:52 ` [patch net-next v2 11/13] net: devlink: use devlink_port pointer instead of ndo_get_devlink_port Jiri Pirko
2022-10-03 10:52 ` [patch net-next v2 12/13] net: remove unused ndo_get_devlink_port Jiri Pirko
2022-10-03 10:52 ` [patch net-next v2 13/13] net: expose devlink port over rtnetlink Jiri Pirko
2022-10-03 16:45 ` Jakub Kicinski [this message]
2022-10-04 6:56 ` [patch net-next v2 00/13] net: fix netdev to devlink_port linkage and expose to user Jiri Pirko
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=20221003094556.1f16a255@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jiri@resnulli.us \
--cc=linux-rdma@vger.kernel.org \
--cc=moshe@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).