- move mask to hot primarily read only cache line
- check mask first to avoid overhead of a function call
- don't collect entropy on ethernet by default
This is rx of ~2.9Mpps on a 2x8x2 SKL
This is rx of ~4Mpps
We're suffering major performance degradation doing this.
However, there's more to unpack here:
random_harvest_queue(m, sizeof(*m), 2, RANDOM_NET_ETHER);
We're sampling harvest size (8 bytes) from the start of the mbuf. So we're literally only ever getting the m_next pointer (the first field of the mbuf). Assuming this were actually set this would be a poor source of entropy. There are only a few thousands of mbufs allocated at low activity. However, unless you're running with jumbo frames, m_next will _always_ be null on ether_input. And, anyone running in production using jumbo frames will have turned this off. So, in the entire time since this change went in we've never gotten any entropy from this source.
Correction: it will be non-NULL on LRO packets. Nonetheless, the point holds.
More generally we need to see a lot more rigor in the justifications surrounding random's design, entropy collection needs, and entropy collection points.
- How much entropy does random actually need?
- How much is it actually getting from a given source?
- Why aren't we using hardware entropy sources? When can we?
There are statistical tests to qualify these things. I think it's quite reasonable that we require a more substantive justification for the overhead than any that have been given to date. We're allowing very poor optics for FreeBSD on the basis of what appears to at best be conjecture.