On Wed, Dec 27, 2023 at 2:01 AM Philo Lu <lulie@xxxxxxxxxxxxxxxxx> wrote: > > The patch set introduce a new type of map, BPF_MAP_TYPE_RELAY, based on > relay interface [0]. It provides a way for persistent and overwritable data > transfer. > > As stated in [0], relay is a efficient method for log and data transfer. > And the interface is simple enough so that we can implement and use this > type of map with current map interfaces. Besides we need a kfunc > bpf_relay_output to output data to user, similar with bpf_ringbuf_output. > > We need this map because currently neither ringbuf nor perfbuf satisfies > the requirements of relatively long-term consistent tracing, where the bpf > program keeps writing into the buffer without any bundled reader, and the > buffer supports overwriting. For users, they just run the bpf program to > collect data, and are able to read as need. The detailed discussion can be > found at [1]. Hold on. Earlier I mistakenly assumed that this relayfs is a multi producer buffer instead of per-cpu. Since it's actually per-cpu I see no need to introduce another per-cpu ring buffer. We already have a perf_event buffer. Earlier you said: "I can use BPF_F_PRESERVE_ELEMS flag to keep the perf_events, but I do not know how to get the buffer again in a new process. " Looks like the issue is lack of map_fd_sys_lookup_elem callback ? Solve the latter part. perf_event_array_map should be pinnable like any other map, so there is a way to get an FD to a map in a new process. What's missing is a way to get an FD to perf event itself.
