LGTM

This function is quite fragile and sensitive.
The more time we spend fixing issues, the more fragile it seems to become.

We have developers that are twice younger than obsoletion of this type.

Looks like I'm not qualified to approve this one. 🚶

@gallatin
So, I can update this revision to:

@zlei All the points you made are valid. I will work on it.

I also faced this problem yesterday.

I'm not expert enough to approve, but this LGTM.

I also reviewed the code under sys/netinet6.

I've reviewed the code under sys/net/

I removed the m_len check because now the rss_mbuf_software_hash_v[46] function performs it.

Use rss_mbuf_software_hash_v* instead. Tested in production and it PERFECTLY works. @gallatin how it looks now?

In D60589#1389297, @glebius wrote:

This is correct fix, thanks! The commit message should be like this:

The work queued by ng_send_fn() is intentionally processed outside of the epoch in ngthread().  It is ng_ksocket's responsibility to enter epoch if it decides to send data from such work.

Nothing to do with ng_ppp.

In D59849#1389238, @adrian wrote:

This looks good to me. I'm glad we finally have this heh. :-)

Address @gallatin comments. Thank you so much, it looks so much better now.

I'm not sure how to make this symmetric, I need help (@glebius @markj).
Now, I've a panic because of this leak.
Steps to reproduce:

kldload ipsec
jail -c name=repro vnet persist
ifconfig -j repro ipsec0 create inet6 fd00::1/64
jail -r repro

I was trying to do the same thing with PROTO_IF + SI_ORDER_FIRST on VNET_SYSUNINIT. But this version looks better to me. of course it depends on if_epair.

I tried that once, there was a problem with it, but I don't remember anymore...
But that was about 5 months ago, it might be ok now.

Unfortunately, I'm not expert on bridge driver.

Address @gperciva_tarsnap.com comments.

In D48646#1374013, @crest_freebsd_rlwinm.de wrote:

Could the visibility or read/write access of the VXLAN sysctls be limited to the vnet jail that currently contains the interface?

In D60051#1378243, @zarychtam_plan-b.pwste.edu.pl wrote:

For a reason unknown to me, perhaps a temporary failure of Bugzilla, I can't comment on the PR directly, so let me note it here.

I cannot reproduce this failure described in bug 298533 when the network equipment is configured correctly and properly withdraws the old prefix. If the problem occurs after physically moving the interface to a different IPv6 network, the interface should be reconfigured as part of that network change. Without such reconfiguration or a proper prefix withdrawal from the router, I don't think this particular scenario can reasonably be considered an operating system failure.

Address @markj comments.

friendly ping @glebius

LGTM

In D58294#1373614, @ziaee wrote:

What happened to the docs?

@zlei: Are you still working on this?
It would be nice to have vnet support for this driver.
I could help if you don't have time.

Since I didn't touch the hash table logic. the proposed change is quite simple.
most of the logic is around net.link.gre.key_fallback for backward compatibility.
I'd be glad to remove the fallback logic, but beside our own compatibility break, Linux can be configured with separate inbound/outbound key.
So I decided to keep the fallback for now.

I really want to keep gre simple and use my own geneve driver. but censorship in my country is not geneve friendly...
Tests are similar to each other, but they're important because we separate ipv4 and ipv6 logic.

We should migrate to rfc9083 sooner or later...
Also please rebase it to main. I can't test it.

This looks good to me. Definitely better than blindly sleeping on dad_count.
But I'm not an expert in shell scripting.
Let me ask and I'll add more reviewers for scripting part.

I will take a look

Address @markj comment. You're right, sorry about that

Address @markj comments.

I think I should explain what happens here, I'll start from relationships between routing modules:

Use only idx for ifname lookup. @glebius done.

Style

Style

• Unregister ignored options from default PRL. @kfv done.

• Disassociate the ip address on release.

• Implement the optional DHCPRELEASE part of the RFC: "It also MAY send a DHCPRELEASE message."
• Respect "ignore ipv6only" in dhclient.conf
• Free snl allocation
• cancel other timers with respect to INIT-REBOOT state

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.