And, with this change, it seems we no longer require nexthop to be loopback interface (V_lo) for blackhole / rejected routes.

Is this a replacement of D46301 ?

Looks good to me.

Looks good to me.

Also encounter this issue on VMware Fusion (13.5.2). @yuripv May you please MFC this fix to stable/13 branch , or I can do that if no objections ?

Do you hint that one listening socket can have multiple / change the fib number ? That sounds not possible

Well, what if we allow changing the fib number of listening socket, so filtering new connections based on the new fib number ?

In D47384#1080748, @melifaro wrote:

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.

Looks good to me.

In D47314#1079145, @kib wrote:

This is indeed a workaround, I remember fixing something similar for ports' variant of if_re. The fix was to move the ether_ifattach() after the media structures are initialized,
https://github.com/alexdupre/rtl_bsd_drv/commit/2a97cc982d0362b69040d1c849f697ff61e37106

I did not looked at the bge code to confirm that it is the case.

Landed as c59a5fbd8a2e (ena: Fix driver unload crash).

In D47332#1079398, @igoro wrote:

Another point is how to deal with sysctl which are "per jail" and vnet-related as well. I guess, they could end up with both flags?

sysctl: Add missing CTLFLAG_PRISON to security.jail.children.*

This looks good to me.

Added -J flag to filter jail prison variables.

This change is focusing on VNET variables, but is open for -J ( CTLFLAG_PRISON ) if requested.

Use -V instead. Added Xr jail 8 .

Add network and Jails people if they have interests on this.

In D47234#1077261, @kp wrote:

It's not as straightforward for '-A' as it'd be for other options, but we should look into writing a test case for this too.
Known bugs are an obvious candidate for test cases after all.

In D46794#1077535, @stephan.dewt_yahoo.co.uk wrote:

In D46794#1076717, @zlei wrote:

Is that specific to FreeBSD only ? I do not see this workaround in Linux driver https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/amd/xgbe/xgbe-dev.c#L2855 .

I don't know for sure, but chances are this issue has never been seen on Linux given the low adoption.

Looks good to me.

A following fix for the netlink based implementation requires this refactoring

In D46794#1076531, @stephan.dewt_yahoo.co.uk wrote:

Just to comment on the unconditional promisc mode initialization, this is shown in more detail here: https://github.com/freebsd/freebsd-src/blob/main/sys/dev/axgbe/xgbe-dev.c#L2032-L2036.

Rebased onto latest main.

I'd like to push this to main and MFC to stable/14. Any objections ?

My personal usage is get vnet tunables via the combination of -J and -T. This has been in my local working tree for quite a long time, mainly to support working on D39638 .

This should also fix https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275381 . See also D42678 .

Address @Jose 's comment.