On Thu, Feb 27, 2025 at 5:16 PM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote:
>
> Hi,
>
> On 2/28/2025 5:10 AM, Alexei Starovoitov wrote:
> > On Fri, Feb 14, 2025 at 9:30 AM Alexei Starovoitov
> > <alexei.starovoitov@xxxxxxxxx> wrote:
> >> On Thu, Feb 13, 2025 at 11:25 PM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote:
> >>> Hi,
> >>>
>
> SNIP
> >>>
> >>> 3) ->map_check_btf()
> >>>
> >>> In ->map_check_btf() callback, check whether the created map is
> >>> mismatched with the dynptr key. If it is, let map_create() destroys the map.
> >> map_check_btf() itself can have the code to filter out unsupported maps
> >> like it does already:
> >> case BPF_WORKQUEUE:
> >> if (map->map_type != BPF_MAP_TYPE_HASH &&
> >> map->map_type != BPF_MAP_TYPE_LRU_HASH &&
> >> map->map_type != BPF_MAP_TYPE_ARRAY) {
> >> ret = -EOPNOTSUPP;
> >>
> >> I don't mind moving map_check_btf() before ->map_alloc_check()
> >> since it doesn't really need 'map' pointer.
> >> I objected to partial move where btf_get_by_fd() is done early
> >> while the rest after map allocation.
> >> Either all map types do map_check_btf() before alloc or
> >> all map types do it after.
> >>
> >> If we move map_check_btf() before alloc
> >> then the final map->ops->map_check_btf() should probably
> >> stay after alloc.
> >> Otherwise this is too much churn.
> >>
> >> So I think it's better to try to keep the whole map_check_btf() after
> >> as it is right now.
> >> I don't see yet why dynptr-in-key has to have it before.
> >> So far map_extra limitation was the only special condition,
> >> but even if we have to keep (which I doubt) it can be done in
> >> map->ops->map_check_btf().
> > Any update on this ?
> > Two weeks have passed.
> > iirc above was the only thing left to resolve.
> Er, I started adding bpffs seq-file and batched operation support
> recently. I need to ask whether it is OK to complete these todo items
> shown below in the following patch-set. As noted in the cover letter,
> the following things have not been supported yet:
>
> 1) batched map operation through bpf syscall
> 2) the memory accounting for dynptr (aka .htab_map_mem_usage)
> 3) btf print for the dynptr in map key
> 4) bpftool support
> 5) the iteration of elements through bpf program
All these things would be nice to add, but the patch set
needs to stay review-able.
It's 20 patches already which is too high.
v1 was done many months ago and not only complexity of the feature
makes it slow to land, but the size of the set too.
Keep it small. Incremental work is preferred.
Better to land the core feature first and then gradually
add 5,2,3,4.
Batched ops aka 1 can be delayed for some time.
