mbox series

[RFC,net-next,00/15] devlink: code split and structured instance walk

Message ID 20221215020155.1619839-1-kuba@kernel.org (mailing list archive)
Headers show
Series devlink: code split and structured instance walk | expand

Message

Jakub Kicinski Dec. 15, 2022, 2:01 a.m. UTC 
Hi!

I started working on the refcounting / registration changes
and (as is usual in our profession) I quickly veered off into
refactoring / paying technical debt. I hope this is not too
controversial.

===

Split devlink.c into a handful of files, trying to keep the "core"
code away from all the command-specific implementations.
The core code has been quite scattered before. Going forward we can
consider using a source file per-subobject, I think that it's quite
beneficial to newcomers (based on relative ease with which folks
contribute to ethtool vs devlink). But this series doesn't split
everything out, yet - partially due to backporting concerns,
but mostly due to lack of time. 

Introduce a context structure for dumps, and use it to store
the devlink instance ID of the last dumped devlink instance.
This means we don't have to restart the walk from 0 each time.

Finally - introduce a "structured walk". A centralized dump handler
in devlink/netlink.c which walks the devlink instances, deals with
refcounting/locking, simplifying the per-object implementations quite
a bit.

Jakub Kicinski (15):
  devlink: move code to a dedicated directory
  devlink: split out core code
  devlink: split out netlink code
  devlink: protect devlink dump by the instance lock
  netlink: add macro for checking dump ctx size
  devlink: use an explicit structure for dump context
  devlink: remove start variables from dumps
  devlink: drop the filter argument from devlinks_xa_find_get
  devlink: health: combine loops in dump
  devlink: restart dump based on devlink instance ids (simple)
  devlink: restart dump based on devlink instance ids (nested)
  devlink: restart dump based on devlink instance ids (function)
  devlink: uniformly take the devlink instance lock in the dump loop
  devlink: add by-instance dump infra
  devlink: convert remaining dumps to the by-instance scheme

 include/linux/netlink.h                 |    4 +
 net/Makefile                            |    1 +
 net/core/Makefile                       |    1 -
 net/devlink/Makefile                    |    3 +
 net/{core/devlink.c => devlink/basic.c} | 1457 ++++++-----------------
 net/devlink/core.c                      |  345 ++++++
 net/devlink/devl_internal.h             |  205 ++++
 net/devlink/netlink.c                   |  241 ++++
 net/netfilter/nf_conntrack_netlink.c    |    2 +-
 9 files changed, 1157 insertions(+), 1102 deletions(-)
 create mode 100644 net/devlink/Makefile
 rename net/{core/devlink.c => devlink/basic.c} (90%)
 create mode 100644 net/devlink/core.c
 create mode 100644 net/devlink/devl_internal.h
 create mode 100644 net/devlink/netlink.c

Comments

Jacob Keller Dec. 15, 2022, 7:39 p.m. UTC | #1 
On 12/14/2022 6:01 PM, Jakub Kicinski wrote:
> Hi!
> 
> I started working on the refcounting / registration changes
> and (as is usual in our profession) I quickly veered off into
> refactoring / paying technical debt. I hope this is not too
> controversial.
> 
> ===
> 
> Split devlink.c into a handful of files, trying to keep the "core"
> code away from all the command-specific implementations.
> The core code has been quite scattered before. Going forward we can
> consider using a source file per-subobject, I think that it's quite
> beneficial to newcomers (based on relative ease with which folks
> contribute to ethtool vs devlink). But this series doesn't split
> everything out, yet - partially due to backporting concerns,
> but mostly due to lack of time. 
> 
> Introduce a context structure for dumps, and use it to store
> the devlink instance ID of the last dumped devlink instance.
> This means we don't have to restart the walk from 0 each time.
> 
> Finally - introduce a "structured walk". A centralized dump handler
> in devlink/netlink.c which walks the devlink instances, deals with
> refcounting/locking, simplifying the per-object implementations quite
> a bit.
> 

I'm fine with the series as-is.

Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

Moving the dumpit_one thing into generic netlink files seems ok, but I
trust you may have already thought about and decided it was too devlink
specific.

Thanks,
Jake