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?

It isn't write only variable. At line 501 original IP header can be changed, this variable keeps its copy.

In D32563#735219, @bz wrote:

Has anyone checked what this was before the epoch work came in?

LGTM.

LGTM.

Ah, sorry, I committed the fix already..

I have no objection.

In D30764#691856, @markj wrote:

p is a union of struct mbuf ** and void *. So wouldn't setting *p.m do the wrong thing if the packet is passed with PFIL_MEMPTR?

I think we can set *p.m unconditionally, like we do in ipfw_check_packet().

The intent of this review was show how we can reduce vlan handling call path. It is not targeted to be included in main stream.