I've improved an answer I wrote a while ago which provides a detailed description of how tcpdump uses a BPF filter:

I was going to also explain how it's done in the kernel, but that turned out to be way more complex than I expected, so I'm thinking to limit it to the BPF interpreter, but does anyone use just the interpreter anymore?

Would it actually be useful to anyone or does no one have net.core.bpf_jit_enable=0 these days?

Do people who use BPF even need to understand how it works internally?

They don't need to, but it'd improve their understanding either way.

eh, then why worry about if anyone is using the interpreter?

Any explanation would improve most people's understanding, I guess

Probably. I guess I'll do that.

Small question about x86 if anyone knows: I have some memory that I need to use very frequently (read: it will almost always be in the L1 cache), but there's a risk that it'll be corrupted, so I use Intel's native CRC instructions to check it before each use. Assuming any corruption will bypass the cache, is there any way to optimize this so I'm not constantly doing a CRC on data that's in cache? Some sort of "CRC only if cache hit AND cache is coherent"?

Performance is very important, so I'm using handwritten x86 assembly for this. And corruption, if undetected, means total destruction of a lot of important data on a whole redundant RAID array.

Right now it's fine because I do the CRC check on each access, but it feels a bit wasteful to be CRCing data that's in the L1 cache over and over and over when it'll only get changed in RAM (thus corruption will only occur if there are cache misses all the way to LLC and it has to fetch it from RAM). It'd be really nice to only checksum when the data is dirty.

This may be a really stupid question, but I really don't know much about x86. Like, I had to look up how MESIF works.

(All I knew is that Intel uses MESIF and AMD uses MOESI and that they have to do with cache coherency for NUMA)