Generally LGTM, with the nit around NHF_BROADCAST

Generally LGTM

Let’s make sure that the constants /macro still has the same type as in Linux and check that, for example, net/bird2 compiles without additional warnings after this change

In D47384#1080729, @markj wrote:

In fact, this probably does not go far enough. I'm not sure when it's useful to change the fibnum of a socket after creation time, but it's dangerous in general since the fibnum is also inherited by the inpcb.

What about multi-fib-aware applications? For example, nginx allows to specify a specific fib for each listening socket.

I'm going to come up with a different version of this patch (likely using a new flag rtmsg->rtm_flags to signal RTM_F_FORCE) in a day or two. The current version allows all netlink customers to fully bypass PINNED route protection, which defeats its purpose.

Netlink support has been added, should not be an issue anymore

Thank you for working on this!
Could you please add the patch with context & add a corresponding test?
Thank you!

Ty for working on that! IIRC the idea of rib_decompose_notification was to provide the same handling for both multipath and non-multipath routes for the callers that care only about specific paths. I'd rather add the relevant callback to the rib_decompose_notification() and not touch nd6_subscription_cb code.

Got it. From my pov we're now requiring explicit mental effort (and knowledge) that each field now comes with a bit, and field mutations may need flag updates. Often after some time it ends up with flags not being consistent, leading to hard-to-debug errors..
I don't have a _strong_ opinion on this, so won't object to the current version - and hope there won't be 'I told you so' situation in a year :-)

LGTM, q - would it be possible to introduce ‘ip6po_<set|clear>_<field>’ inline functions and use them so we don’t accidentally miss setting/clearing up the relevant bit?

I’ a bit unsure about this one - as having pointer to bool may introduce

I agree we should rootcase the case. However - why do we need to perform these conditional checks everywhere?
Why can’t t_cc refer to the dummy cc structure? Why can’t the non-implemented/non-needed function point to no-op functions?

Thank you for submitting the patch. I’m not sure I fully understand the problem and the solution.
Could you please provide some examples?

Thank you for updating the interface to netlink!
Generally LGTM, the only concern I have is about using sockaddrs inside netlink..

Thank you for adding it! It's certainly nice to have an integrated solution for PF. Conceptually I'm all up for it.
For the control path implementation I'll second Glebius concern - it's pretty ugly to build a cloner, a bunch of interfaces to allow to use (non-extendable) interface ioctls..
I'd really suggest doing gentlink family with CREATE|UPDATE/DELETE/GET interface, which will be easily extendable. It may even be less code that it is now.

Thanks for working on the idea of improving tests parallelism!
Conceptually I like the idea of auto-jailing, but the details matter :-)
Jails deal nicely with removing some tests-running side-effects, but not all.
Filesystem “virtualization” as well as network “virtualization” has to be set up explicitly to actually provide isolation for the respective tests.

I’d rather avoid doing that. ntohs is fast and branchless, so I’d vote for optimizing for readability here (unless there is a measurable performance gain)

In D42170#962312, @imp wrote:

opt_global.h is ok. Opt_proto just moves th problem.

But we actually have it for inet/inet6 as well. I ran into the similar issues many times..

In D42170#962271, @kp wrote:

Should we do the include in the headers that directly need it instead? That'd be at least netlink_ctl.h, netlink_message_writer.h and route/route_var.h.

This seem a bit contrary to the approach used in the other parts of the kernel. If really want to switch the pattern, I’d ether vote for opt_proto ( or opt_global.h)

In D42170#962265, @markj wrote:

In D42170#962264, @markj wrote:

One caveat of this approach is that netlink/netlink.h has to be included before all headers which might expect NETLINK to be defined. For instance, it'll be a bug for .c files to include netlink.h after netlink_ctl.h. Maybe the solution there is to make netlink_ctl.h include opt_netlink.h as well, I'm not sure.

Another solution is to just define NETLINK in opt_global.h. I've never found having separate option headers to be useful.

I was thinking in a similar way, having opt_proto.h which contains defines for INET, INET6 and NETLINK, so a whole variety of errors would be eliminated..

In D40213#943667, @dfr wrote:

Would there be any objection to me merging this change and the related change in D40377 to stable/13? It would make setting up container networking for containerd and nerdctl much simpler. For podman, it could also make networking more efficient - we currently use two jails per container with one solely used to own the container vnet while also allowing access to host networking tools.

No objection, the only note is that ifconfig(8) code is different in stable/13, so likely it would require some changes.

Overall is a really nice addition and I'd love to have it in base. I have one concern on the rule import/export implementation - happy to discuss this further & left a couple of non-critical comments on the code.
Thank you for working on this!

In D40577#923867, @jhibbits wrote:

I agree with option 1, moving the LLE insertion code to if_llatbl.c

Yep. I drafted something, but I need to think about the desired KPI a bit more, as I want to accommodate child LLE inclusion (IPv4 over IPv6 LLEs ATM). Probably I'll come up with something in the next couple of days.

I guess it deserves some discussion on the interface model part. The alternative fix can be done on the Netlink side (try to avoid calling driver-specific ioctls on the ifarrival event) or by moving ifnet_arrival event later in the chain.
My question is what are the desired ether_ifattach() and ifnet_arrival calls/events semantics. Does the ifnet_arrival event mean "interface is fully ready" so it can be queried/updated for the caller? If not, how can the event listener get notified on the readiness?