RX_Ring: Remove extra blocks data structure

[awelzel]

Okay, this might be naive. Both Suricata and the AF_PACKET example [1] keep the block descriptor offsets in a separately allocated table as well.

From all I can tell, that allocation isn't really needed if we're okay computing the address of the block based on the beginning of the mmap'ed memory region using the tp_req parameters. That shouldn't be slower

[1] https://docs.kernel.org/networking/packet_mmap.html#af-packet-tpacket-v3-example

[J-Gras]

I don't see a reason why calculating the address ad-hoc shouldn't work. However, I am wondering why no one else does it this way. I would be surprised to see any significant difference, but did you check the performance impact?

[awelzel]

I would be surprised to see any significant difference, but did you check the performance impact?

I have not, this probably needs a patched Zeek version to not call dispatch_packet() at all and then send a lot of syn packets and :crossed_fingers: for seeing something.

We can leave this open and maybe at some point can test.

[awelzel]

It seems gopacket does not use a auxiliary data structure: https://github.com/google/gopacket/blob/32ee38206866f44a74a6033ec26aeeb474506804/afpacket/afpacket.go#L450-L452

They do keep a header for the current block to avoid computing it for every packet anew, but the comments indicate that's more because they'd allocate a v3wrapper object over and over again: https://github.com/google/gopacket/blob/32ee38206866f44a74a6033ec26aeeb474506804/afpacket/afpacket.go#L307

Anyway, we could add caching of the pointer for the current block and then it should be fine to get rid of the blocks data structure, even without a real perf test.