Probably for network related code ENOBUFS is better than ENOMEM.

I think you need to modify IFF_CANTCHANGE in sys/net/if.h

• Document some features, also reduce the diff.
• Fix bug in mac:radix table: lookup addr doesn't work due to wrong args order in memcpy

• Document some features, also reduce the diff.

Maybe it would be better implement such feature via named flag, like ignore_source is implemented? Also if_gre(4) has the same problem.

In D45762#1045093, @glebius wrote:

I think you should had not abandon this revision. enc(4) creates suboptimal packets, and this should be improved. Hence I suggested to use __predict_false() in the pf(4) review.

I think it is firewall problem when it can not handle some unexpected data. Pfil hook expects that mbus has M_PKTHDR and m->m_pkthdr.len in this case should not be 0, even when m_len is 0. Thus, I think if doesn't work properly, it should be fixed in firewall.

Probably you can simplify some similar checks in in6_src.c too, e.g. IP6PO_VALID_PKTINFO and IP6PO_VALID_NHINFO. Not sure how it impacts your cache misses measurements.

Probably we should increase esps_notdb or esps_invalid counter here.

I think https://reviews.freebsd.org/D32811, https://reviews.freebsd.org/D33064 also are related.

In D42988#981761, @glebius wrote:

Do you plan to rework access to if_afdata? There are still several panics related to access to already freed if_afdata[AF_INET6].

Can you please assign those PRs to me? Or send links to information if there is no PR.

Isn't IPv6 part affected too?

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: