Re: [PATCH v3 net-next 00/15] neighbour: Namespacify arp_tbl and nd_tbl.

On Tue, Aug 11, 2026 at 9:55 AM Ido Schimmel <[email protected]> wrote:
>
> On Tue, Aug 11, 2026 at 02:23:34AM +0000, Kuniyuki Iwashima wrote:
> > The neighbour subsystem is almost ready to drop RTNL.
> >
> > However, the control paths are serialised by the global
> > per-table lock.
> >
> > This series converts arp_tbl and nd_tbl to per-netns table.
> >
> > Patch 1 deflakes test_neigh.sh.
> >
> > Patch 2 ~ 3 are misc cleanup.
> >
> > Patch 4 ~ 7 store arp_tbl/nd_tbl to net->neigh_tables[] and
> > remove the global neigh_tables[].
> >
> > Patch 8 ~ 9 replace the direct access to arp_tbl/nd_tbl to
> > net->neigh_tables[] using new helpers.
> >
> > Patch 10 ~ 12 finally replace the global table with per-netns
> > table.
> >
> > Patch 13 ~ 14 clean up unnecessary net_eq().
> >
> > Patch 15 updates test_neigh.sh.
>
> The change is good, but the cover letter should explicitly state that
> this patchset introduces a behavior change with a regression potential
> (as evident by patch 15).

Indeed, I'll add notes in the cover letter and patch 12 and
move two parts of diff in patch 14 (neightbl_set() and
lookup_neigh_param()) to patch 12.


>
> I'm aware of at least one deployment that will most likely regress
> without some changes in user space before upgrading the kernel. In this
> deployment, the host has several namespaces representing different
> routers with hundreds/thousands neighbours in each namespace.
> Currently, they set the GC thresholds in the initial namespace so that
> they are high enough for all the namespaces combined. With this
> patchset, the GC thresholds in the initial namespace will no longer
> affect the other namespaces and the routers will fail because the
> default thresholds (128/512/1024) are too low.
>
> I can ask them to keep doing what they are doing, but also set the
> per-namespace GC thresholds. It will fail on current kernels (harmless),
> but work on future ones. Similarly for the base reachable time which
> currently they set in the initial namespace to the maximum among all
> namespaces.
>
> Another thing worth a discussion is the policy regarding the initial
> values in each namespace. With this patchset, new namespaces all get the
> same default values instead of inheriting from the initial namespace:
>
> # sysctl net.ipv4.neigh.default.gc_thresh1
> net.ipv4.neigh.default.gc_thresh1 = 128
> # sysctl -wq net.ipv4.neigh.default.gc_thresh1=129
> # ip netns add ns1
> # ip netns exec ns1 sysctl net.ipv4.neigh.default.gc_thresh1
> net.ipv4.neigh.default.gc_thresh1 = 128
>
> Assuming that today people configure the initial namespace before
> creating namespaces, changing the policy to inherit from the initial
> namespace will probably result in fewer regression reports. There is a
> knob that controls this policy for other settings (see
> devconf_inherit_init_net).

I considered adding a new knob like tcp_chlid_ehash_entries to
control the behaviour, but I was wondering if it might be rather
confusing to people in the future that only GC attributes are inherited.
But I don't have strong preference here.