Not sure but it might help with PR292319

In D53742#1350387, @rscheff wrote:

maybe something like this; I suppose if this is after all the includes, it's scoped only within this source file.

#undef IPV6_ECN
#define IPV6_ECN(ipv6_flow) ((ntohl(ip6_flow) >> IPV6_FLOWLABEL_LEN) & 0x03)

conversely, the setting of the ECN can be done again with a macro override in the subsequent function.
Gleb may also have some input on this kinds of shenanigans; with the macro I feel more people would more readly understand what is going on here.

This change is good by nature. but it would be nice to have a comment above sa_equal in case we forget the original issue

FYI: @bms, I redesigned the current fib_algo to support neighbor families other than extra 4o6. Subhash Murmu (MPLS GSoC student) can increase FD_MAX_NH_AF and reuse it for its own dataplane.

In D56637#1366756, @zarychtam_plan-b.pwste.edu.pl wrote:

I am still testing it 24/7 on my laptop and can confirm that dhclient with this patch is working great!

What if the application set the sin6_flowinfo too?

In D45102#1366629, @markj wrote:

Is there a reason we shouldn't go ahead with this?

Sorry, I think I abandon it too soon.
@glebius, do you have any suggestion?

In D59387#1362617, @glebius wrote:

You definitely found the problem, but the fix doesn't seem correct. There is asymmetry in allocation/freeing. It could close the leak at some configurations without regressions, of course. But IMHO not at all configurations.

First, the stack allocates single address, but frees the entire list. Can this be made symmetrical and only ifp->if_addr is freed by the stack?
Second, allocation happens always, but freeing is under #ifdef VIMAGE.

In D59387#1362564, @markj wrote:

But where is the leak? Shouldn't each interface be responsible for removing its addresses when it's destroyed?

I'm not sure if this is the right approach because if_detach_internal() is not the only consumer of if_delgroup. But since we're using ck_queue here, I think it should be fine.
I prefer to have other opinions on this change as well.

In D59160#1357307, @paulo_nlink.com.br wrote:

@pouria MLD's role is informing snooping switches and multicast routers where to forward group traffic so they can prune instead of flooding (RFC 4541). So "ND relies on MLD" holds on fabrics whose switches prune by snooping

Thank you for your contribution.
I understand your concern.
I've encountered similar policies at multiple IXPs as well. (ofc not for MLD)

LGTM

netstat.1: Remove -N/-M options in -o/-O, but keep the -j/--libxo for those options.

Address @kfv comments. Thank you!

Thank you!

Friendly ping @ziaee

Rebase on top of D58775 and replace struct iflaf_group with snl_parray

Rebase on top of D58775 and replace struct iflaf_group with snl_parray

LGTM
Thank you!
I'll rebase D58644 on top of this and replace my parray to multi-attr.
It *might* also need a version bump.

Address @kfv comment. Thanks!

friendly ping @tuexen @rscheff

Delay lock in fib_module_unregister.

Address @markj comments.

Unlock earlier in fib_check_best_algo.

In D58803#1349648, @markj wrote:

You can dig deeper: where are the lock acquisitions coming from? Use stack(). Is there actual lock contention? Use lockstat:::adaptive-spin/adaptive-block to look for this. See dtrace_lockstat(4).

In D58803#1349425, @markj wrote:

Something like dtrace -n 'lockstat:::adaptive-acquire /args[0]->lock_object.lo_name == "algo list mutex"/{printf("hi");}' can be used to get a sense for how often this lock is acquired.

friendly ping @melifaro

In D58803#1349400, @markj wrote:

In D58803#1349394, @pouria wrote:

In D58803#1349372, @markj wrote:

In D58803#1349353, @pouria wrote:

In D58803#1349330, @markj wrote:

But why do this? What do we gain? These operations are rare. In such code, it is better to keep things simpler and "obviously correct." You're right that we can now probably drop that one use of the fib module lock, but now the code is harder to reason about and debug, and we do not gain anything in return (that I can see, at least).

Unfortunately, if you're using the radix[6]_lockless algorithm, which is usually true for IPv6, these operations happen frequently.
This is what I found while debugging PR297339.

You can test it yourself, set sysctl net.route.algo.debug_level=8 and try to keep a simple routing daemon for routes under 10k.
Then you see these functions are frequently run must of the time.
Since radix[6]_lockless rebuilds itself on every change.

I'm trying to cleanup fib_algo file.
It's too hard to work on it with radix_lockless.

What does "frequently" mean? Once a second? Ten thousand times a second? Does the change actually help performance in some measurable way?

Ok, I just run the dtrace below on my IXP router (unmodified CURRENT kernel).
This might answer your question:
[...]
dtrace.s:

fbt:kernel:fib_unref_nhop:entry
{
fib_calls++;
}

BTW, this is racy, see the note here https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/dtrace-guide/variables-dtrace.html

Better would be to use an aggregation: @calls = count();

tick-1s
{
printf("%Y | fib_unref_nhop calls/sec: %d\n", walltimestamp, fib_calls);
fib_calls = 0;
}

Ok, but fib_unref_nhop() doesn't acquire the module lock.

I had to restart my router because of radix6_lockless memory leak.
The output below is RIGHT after boot with DPDK:

[pouria@nanali] [~] % uptime
11:29PM  up 45 secs, 1 user, load averages: 2.25, 0.55, 0.20
[pouria@nanali] [~] % kldload dtraceall
kldload: can't load dtraceall: Operation not permitted
[pouria@nanali] [~] % mdo kldload dtraceall
[pouria@nanali] [~] % mdo dtrace -s stats.d
2026 Aug 12 23:29:39 | fib_unref_nhop calls/sec: 6932
2026 Aug 12 23:29:40 | fib_unref_nhop calls/sec: 6580
2026 Aug 12 23:29:41 | fib_unref_nhop calls/sec: 7452
2026 Aug 12 23:29:42 | fib_unref_nhop calls/sec: 8890
2026 Aug 12 23:29:43 | fib_unref_nhop calls/sec: 6836
2026 Aug 12 23:29:44 | fib_unref_nhop calls/sec: 6776
2026 Aug 12 23:29:45 | fib_unref_nhop calls/sec: 5161
2026 Aug 12 23:29:46 | fib_unref_nhop calls/sec: 9029
2026 Aug 12 23:29:47 | fib_unref_nhop calls/sec: 8917
2026 Aug 12 23:29:48 | fib_unref_nhop calls/sec: 7426
2026 Aug 12 23:29:49 | fib_unref_nhop calls/sec: 3824

In D58803#1349372, @markj wrote:

In D58803#1349353, @pouria wrote:

In D58803#1349330, @markj wrote:

But why do this? What do we gain? These operations are rare. In such code, it is better to keep things simpler and "obviously correct." You're right that we can now probably drop that one use of the fib module lock, but now the code is harder to reason about and debug, and we do not gain anything in return (that I can see, at least).

Unfortunately, if you're using the radix[6]_lockless algorithm, which is usually true for IPv6, these operations happen frequently.
This is what I found while debugging PR297339.

You can test it yourself, set sysctl net.route.algo.debug_level=8 and try to keep a simple routing daemon for routes under 10k.
Then you see these functions are frequently run must of the time.
Since radix[6]_lockless rebuilds itself on every change.

I'm trying to cleanup fib_algo file.
It's too hard to work on it with radix_lockless.

What does "frequently" mean? Once a second? Ten thousand times a second? Does the change actually help performance in some measurable way?

In D58803#1349330, @markj wrote:

But why do this? What do we gain? These operations are rare. In such code, it is better to keep things simpler and "obviously correct." You're right that we can now probably drop that one use of the fib module lock, but now the code is harder to reason about and debug, and we do not gain anything in return (that I can see, at least).

Wanted to make sure, here is the removal of FIB_MOD_LOCK in unref_algo.

In D58803#1349302, @glebius wrote:

That would make sense if you also got rid of FIB_MOD_LOCK() at least for some of the operations. The change as is just adds synchronization inside sections that are already synchronized by the mutex.

Overall, this is a great change. I also wanted to rename parray structure from nexthop-specific names to something more generic too, considering we really need the multi-attr parser in our library too. specially for cases like D58643.

Address @ziaee comment on macro.

In D58565#1347038, @ziaee wrote:

What would be helpful is a Fixes: commit message trailer so we knew how far back this needs to MFC and when.

ping @glebius @markj

ping @kib

ping @glebius @ziaee

ping @glebius

ping @glebius @markj

ping @glebius @markj