On Thu, Dec 28, 2023 at 3:20 AM Philo Lu <lulie@xxxxxxxxxxxxxxxxx> wrote: > > > > On 2023/12/28 02:02, Alexei Starovoitov wrote: > > 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. > > > I think relay map and perfbuf don't conflict with each other, and relay > map could be a better choice in some use cases (e.g., constant tracing). > In our application, we output the tracing records as strings into relay > files, and users just read it through `cat` without any process, which > seems impossible to be implemented even with pinnable perfbuf. > > Specifically, the advantages of relay map are summarized as follows: > (1) Read at any time without extra process: As discussed before, with > relay map, bpf programs can keep writing into the buffer and users can > read at any time. Just add this ability to perf ring buf. > (2) Custom data format: Unlike perfbuf processing data entry by entry > (or event), the data format of relay is up to users. It could be simple > string, or binary struct with a header, which provides users with high > flexibility. perf ring buf allows any format as well. > (3) Better performance: Due to the simple design, relay outperforms > perfbuf in current bench_ringbufs (I added a relay map case to > `tools/testing/selftests/bpf/benchs/bench_ringbufs.c` without other > changes). Note that relay outputs data directly without notification, > and the consumer can get a batch of samples using read() at a time. performance is irrelevant, since relay is unusable from bpf due to dead lock issue I explained in the other email. It's really a nack.
