Re: [Bridge] [GIT PULL] sysctl changes for v6.6-rc1

2023-09-06 Thread Joel Granados
On Wed, Sep 06, 2023 at 01:58:49PM +0200, Alexey Gladkov wrote:
> On Tue, Aug 29, 2023 at 01:44:55PM -0700, Luis Chamberlain wrote:
> > The following changes since commit 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5:
> > 
> >   Linux 6.5-rc1 (2023-07-09 13:53:13 -0700)
> > 
> > are available in the Git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/ 
> > tags/sysctl-6.6-rc1
> > 
> > for you to fetch changes up to 53f3811dfd5e39507ee3aaea1be09aabce8f9c98:
> > 
> >   sysctl: Use ctl_table_size as stopping criteria for list macro 
> > (2023-08-15 15:26:18 -0700)
> > 
> > 
> > sysctl-6.6-rc1
> > 
> > Long ago we set out to remove the kitchen sink on kernel/sysctl.c arrays and
> > placings sysctls to their own sybsystem or file to help avoid merge 
> > conflicts.
> > Matthew Wilcox pointed out though that if we're going to do that we might as
> > well also *save* space while at it and try to remove the extra last sysctl
> > entry added at the end of each array, a sentintel, instead of bloating the
> > kernel by adding a new sentinel with each array moved.
> > 
> > Doing that was not so trivial, and has required slowing down the moves of
> > kernel/sysctl.c arrays and measuring the impact on size by each new move.
> > 
> > The complex part of the effort to help reduce the size of each sysctl is 
> > being
> > done by the patient work of el seƱor Don Joel Granados. A lot of this is 
> > truly
> > painful code refactoring and testing and then trying to measure the savings 
> > of
> > each move and removing the sentinels. Although Joel already has code which 
> > does
> > most of this work, experience with sysctl moves in the past shows is we 
> > need to
> > be careful due to the slew of odd build failures that are possible due to 
> > the
> > amount of random Kconfig options sysctls use.
> > 
> > To that end Joel's work is split by first addressing the major housekeeping
> > needed to remove the sentinels, which is part of this merge request. The 
> > rest
> > of the work to actually remove the sentinels will be done later in future
> > kernel releases.
> 
> This is very interesting for me. I'm also refactoring sysctl based on
> discussion with Linus a while ago.
> 
> Could you please add me to the Cc in the next patches?
I just sent the next batch for this set for review. You can see it here
https://lore.kernel.org/all/20230906-jag-sysctl_remove_empty_elem_arch-v1-0-3935d4854...@samsung.com/
Will add you for the next ones.

Best

> 
> > At first I was only going to send his first 7 patches of his patch series,
> > posted 1 month ago, but in retrospect due to the testing the changes have
> > received in linux-next and the minor changes they make this goes with the
> > entire set of patches Joel had planned: just sysctl house keeping. There are
> > networking changes but these are part of the house keeping too.
> > 
> > The preliminary math is showing this will all help reduce the overall build
> > time size of the kernel and run time memory consumed by the kernel by about
> > ~64 bytes per array where we are able to remove each sentinel in the future.
> > That also means there is no more bloating the kernel with the extra ~64 
> > bytes
> > per array moved as no new sentinels are created.
> > 
> > Most of this has been in linux-next for about a month, the last 7 patches 
> > took
> > a minor refresh 2 week ago based on feedback.
> > 
> > 
> > Joel Granados (14):
> >   sysctl: Prefer ctl_table_header in proc_sysctl
> >   sysctl: Use ctl_table_header in list_for_each_table_entry
> >   sysctl: Add ctl_table_size to ctl_table_header
> >   sysctl: Add size argument to init_header
> >   sysctl: Add a size arg to __register_sysctl_table
> >   sysctl: Add size to register_sysctl
> >   sysctl: Add size arg to __register_sysctl_init
> >   sysctl: Add size to register_net_sysctl function
> >   ax.25: Update to register_net_sysctl_sz
> >   netfilter: Update to register_net_sysctl_sz
> >   networking: Update to register_net_sysctl_sz
> >   vrf: Update to register_net_sysctl_sz
> >   sysctl: SIZE_MAX->ARRAY_SIZE in register_net_sysctl
> >   sysctl: Use ctl_table_size as stopping criteria for list macro
> > 
> >  arch/arm64/kernel/armv8_deprecated.c|  2 +-
> >  arch/s390/appldata/appldata_

Re: [Bridge] [PATCH iproute2-next v3] iplink: bridge: Add support for bridge FDB learning limits

2023-09-06 Thread Petr Machata via Bridge
(I pruned the CC list, hopefully I didn't leave out anybody who cares.)

Johannes Nixdorf via Bridge  writes:

> Support setting the FDB limit through ip link. The arguments is:
>  - fdb_max_learned_entries: A 32-bit unsigned integer specifying the
> maximum number of learned FDB entries, with 0
> disabling the limit.

...

> Signed-off-by: Johannes Nixdorf 

Code looks good to me. A couple points though:

- The corresponding kernel changes have not yet been merged, have they?
  This patch should obviously only be merged after that happens.

- The UAPI changes should not be part of the patch, the maintainers will
  update themselves.

- The names fdb_n_learned_entries, fdb_max_learned_entries... they are
  somewhat unwieldy IMHO. Just for consideration, I don't feel strongly
  about this:

  Your kconfig option is named BRIDGE_DEFAULT_FDB_MAX_LEARNED, and that
  makes sense to me, because yeah, given the word "learned" in context
  of FDB, "entries" is the obvious continuation, so why mention it
  explicitly. Consider following suit with the other source artifacts --
  the attribute names, struct fields, keywords in this patch.
  "fdb_n_learned", "fdb_max_learned" is IMHO just as understandable and
  will be easier to type.