In D42988#980253, @glebius wrote:

The if_afdata[] array comes from the old BSD times when it was expected that there would be support for many many address families (e.g. IPX, AppleTalk, etc). Right now it has only two entries AF_INET and AF_INET6. It is very very very unlikely it will ever get a third one. It is much more likely that the array will go away and we will have just ifp->if_inet and ifp->if_inet6. Or maybe something more complicated. Anyway, the access to this data is going to change anyway, so there is no point in overdesigning it right now. Any solution for the sake of IfAPI cleanness is acceptable.

Looks similar to what linux does.

I don't like adding extra printfs on fast path processing. This can easily make your system unresponsive.

I think previous logic was correct and derived from code before IPsec overhaul.

In D40421#920356, @imp wrote:

This looks generally good.
I think I have an arm server with bt mode. Any chance it will work?

LGTM. Do you plan to implement NAT_T_FRAG in kernel somehow?

LGTM.

we can't recover why would we ever have identical 4-tuples in the hash

I'll try to read the patch more carefully this weekend.

Thanks, the patch is correct.
But I think we need rework the code to avoid such problem in future, or maybe add some comment, or add inline function like this:

Can you take a look at the errata for 82599 that does report checksum error when card receives IPv4 UDP packets with zero checksum?
I found several discussion (on Opensense and FreeBSD forums) about this problem that appeared visible after this commit. Also, I found this PR. In our case we see noticeable RX errors on machines that handle SNMP traps.

Do you plan add similar support for IPv6? There is ICMP6_PACKET_TOO_BIG with the same meaning. But actually it is not unreach message, thus I'm not sure we should do it.

Good explanation. It would be nice to have something similar somewhere in comments.

Superseded by D30398.

There are several comments that don't match our style. Those, that are like:

I think you can go through using of some sysctl/tunable first.
I.e. by default system will use old behavior, but you can change it for your system.

In D33227#755751, @bz wrote:

Because otherwise your listen socket cannot have protected and unprotected connections; 5 BGP speakers do MD5, 7 don't.
The socket option is the "turn the feature on", the SADB is your policy to whom you do MD5 and to whom you don't.

I have no objection. Just a question. What is the reason behind the accepting of non-signed packets on the socket that we explicitly marked that it must use signatures?
I think this will lead to hiding misconfigurations from the user.

I think the patch needs to be updated to reflect epoch related changes in the vlan code.
We use this patch. But I did not checked is it applicable to recent CURRENT or not.

This looks like leftover from D31271.

In D32810#740413, @bz wrote:

This leads to a lot of questions:
(a) can we check for the NULL pointer and gracefully handle it? Or at least add a KASSERT to document it?