Hi, On 12/25/2023 7:36 PM, Philo Lu wrote: > On 2023/12/23 21:02, Philo Lu wrote: >> >> >> On 2023/12/23 19:22, Hou Tao wrote: >>> Hi, >>> >>> On 12/22/2023 8:21 PM, Philo Lu wrote: >>>> 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@xxxxxxxxxxxxxx/T/ > Thanks.
