ringbuf: add zero-copy reader callback API

[jschwinger233]

Ringbuf reads currently copy every sample into a user buffer via Read/ReadInto, even when callers only need to inspect data once. This change adds a zero-copy read API so consumers can process records directly from the mmap-backed ring buffer without an intermediate copy.

Changes

• Add Reader.ReadZeroCopy(callback) to read a record and invoke a callback with a zero-copy sample view plus the remaining-bytes count.
• Refactor the shared read loop so ReadInto and ReadZeroCopy use the same poll/epoll path and error handling.
• Add ringReader.readRecordZeroCopy as the internal zero-copy path; readRecord now delegates to it and performs the copy inside the callback.

API/behavior notes

• Read/ReadInto semantics remain unchanged.
• If the callback returns an error, the record is still consumed (consumer position is advanced) and the error is returned to the caller.

Benchmarks[1]
Results below are from benchmark-result.txt (read-into copy vs read-view zero-copy). Event sizes cover 80–2048 bytes in 16-byte steps (124 sizes).

• Speedup range: 1.00x to 5.63x; median 3.43x (mean 3.16x).
• Small sizes can be flat (e.g., 80B at 1.00x).
• Larger records benefit more as copy throughput drops while zero-copy stays roughly flat.

Sample sizes (Mevents/s):

event-size (B)	copy	zero-copy	speedup
80	43.89	43.70	1.00x
128	42.92	43.82	1.01x
256	28.84	30.97	1.07x
512	24.40	31.42	1.29x
1024	8.97	30.87	3.44x
2048	4.41	24.85	5.63x

[1] https://github.com/jschwinger233/bpf_ringbuf_zc_benchmark

[florianl]

Following the code, I think this function has the potential be used incorrectly?

var saved []byte
reader.ReadZeroCopy(func(sample []byte, remaining int) error {
    saved = sample  // retains reference to temporary memory?
    return nil
})
// is saved still valid at this point?

[orishuss]

Hi @jschwinger233 , thanks for introducing this.
We've indeed found that this copy is unnecessary and in some cases has a significant overhead.

@florianl - your comment makes sense, this API should stay safe.
The problem stems from the fact that in the proposed implementation, one could only use the data until the callback returns, which sometimes isn't enough. For example, one could prefer to batch handle items, but the callback only allows handling 1-by-1.

For this reason I implemented a similar idea, but after using ReadZeroCopy, the memory is available until Commit is called. Would love your review at #1968

[ti-mo]

e2manyproposals, let's continue the conversation in #1968.