Hi,

On 12/25/2023 7:36 PM, Philo Lu wrote:

On 2023/12/23 21:02, Philo Lu wrote:

quoted

On 2023/12/23 19:22, Hou Tao wrote:

quoted

Hi,

On 12/22/2023 8:21 PM, Philo Lu wrote:

quoted

BPF_MAP_TYPE_RELAY is implemented based on relay interface, which
creates per-cpu buffer to transfer data. Each buffer is essentially a
list of fix-sized sub-buffers, and is exposed to user space as
files in
debugfs. attr->max_entries is used as subbuf size and
attr->map_extra is
used as subbuf num. Currently, the default value of subbuf num is 8.

The data can be accessed by read or mmap via these files. For example,
if there are 2 cpus, files could be `/sys/kernel/debug/mydir/my_rmap0`
and `/sys/kernel/debug/mydir/my_rmap1`.

Buffer-only mode is used to create the relay map, which just allocates
the buffer without creating user-space files. Then user can setup the
files with map_update_elem, thus allowing user to define the directory
name in debugfs. map_update_elem is implemented in the following
patch.

A new map flag named BPF_F_OVERWRITE is introduced to set overwrite
mode
of relay map.

Beside adding a new map type, could we consider only use kfuncs to
support the creation of rchan and the write of rchan ? I think
bpf_cpumask will be a good reference.

This is a good question. TBH, I have thought of implement it with
helpers (I'm not very familiar with kfuncs, but I think they could be
similar?), but I was stumped by how to close the channel. We can
create a relay channel, hold it with a map, but it could be difficult
for the bpf program to close the channel with relay_close(). And I
think it could be the difference compared with bpf_cpumask.

I've learned more about kfunc and kptr, and find that kptr can be
automatically released with a given map. Then, it is technically
feasible to use relay interface with kfuncs. Specificially, creating a
relay channel and getting the pointer with kfunc, transferring it as a
kptr into a map, and then it lives with the map.

Yes. kptr of bpf_cpumask can be destroyed by the freeing of map or doing
it explicitly through bpf_kptr_xchg() and release kfunc.

Though I'm not sure if this is better than map-based implementation,
as mostly it will be used with a map (I haven't thought of a case
without a map yet). And with kfunc, it will be a little more complex
to create a relay channel.

The motivation for requesting to implement BPF_MAP_TYPE_REPLAY through
kfunc is that Alexei had expressed the tendency to freeze the stable map
type [1] and to implement new map type through kfunc. However we can let
the maintainers to decide which way is better and more acceptable.

[1]
https://lore.kernel.org/bpf/CAEf4BzZTYcGNVWL7gSPHCqao_Ehx_3P7YK6r+p_-hrvpE8fEvA@mail.gmail.com/T/ (local)

Thanks.