Re: [RFC PATCH 1/7] perf tools: Add API to config maps in bpf object

[Wangnan (F)]

On 2015/10/17 18:48, Wang Nan wrote:
> bpf__config_obj() is introduced as a core API to config BPF object
> after loading. One configuration option of maps is introduced. After
> this patch BPF object can accept configuration like:
>
>   maps.my_map.value=1234
>
> This patch is more complex than the work it really does because the
> consideration of extension. In designing of BPF map configuration,
> following things should be considered:
>
>   1. Array indics selection: perf should allow user setting different
>      value to different slots in an array, with syntax like:
>      maps.my_map.value[0,3-6]=1234;
>
>   2. Type of value: integer is not the only valid value type. Perf
>      event can also be put into a map after commit 35578d7984003097af2b1e3
>      (bpf: Implement function bpf_perf_event_read() that get the selected
>      hardware PMU conuter);
>
>   3. For hash table, it is possible to use string or other as key;
>
>   4. It is possible that map configuration is unable to be setup
>      during parsing. Perf event is an example.
>
> Therefore, this patch does tie following thing for extension:
>
>   1. Instead of update map element during parsing, this patch stores
>      map config options in 'struct bpf_map_priv'. Following patches
>      would apply those configs at proper time;

Because of this delay-updating manner, current implementation forbid
setting a map with different configuration.
For example:

 # perf record -e 
test_bpf.c/maps:channel:value[0...9]=1,maps:channel:value[10...19]=2/ ...

is equal to
 # perf record -e test_bpf.c/maps:channel:value[10...19]=2/ ...

because [see follow]

>   2. Make 'struct bpf_map_priv' extensible so following patches can
>      add new key and value operations;
>
>   3. Use bpf_config_map_funcs array to support more maps configuration.
>
> Signed-off-by: Wang Nan <wangnan0@xxxxxxxxxx>
> Signed-off-by: He Kuang <hekuang@xxxxxxxxxx>
> Cc: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>
> Cc: Alexei Starovoitov <ast@xxxxxxxxxxxx>
> Cc: Brendan Gregg <brendan.d.gregg@xxxxxxxxx>
> Cc: Daniel Borkmann <daniel@xxxxxxxxxxxxx>
> Cc: David Ahern <dsahern@xxxxxxxxx>
> Cc: He Kuang <hekuang@xxxxxxxxxx>
> Cc: Jiri Olsa <jolsa@xxxxxxxxxx>
> Cc: Kaixu Xia <xiakaixu@xxxxxxxxxx>
> Cc: Masami Hiramatsu <masami.hiramatsu.pt@xxxxxxxxxxx>
> Cc: Namhyung Kim <namhyung@xxxxxxxxxx>
> Cc: Paul Mackerras <paulus@xxxxxxxxx>
> Cc: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
> Cc: Zefan Li <lizefan@xxxxxxxxxx>
> Cc: pi3orama@xxxxxxx
> Link: http://lkml.kernel.org/n/ebpf-36xcrahy9n0ayc05mu7aajpk@xxxxxxxxxxxxxx
> ---
>   

[SNIP]

>   
> +enum bpf_map_priv_key_type {
> +	BPF_MAP_PRIV_KEY_ALL,
> +};
> +
> +enum bpf_map_priv_value_type {
> +	BPF_MAP_PRIV_VAL_VALUE,
> +};
> +
> +struct bpf_map_priv {
> +	struct {
> +		enum bpf_map_priv_key_type type;
> +	} key;
> +
> +	struct {
> +		enum bpf_map_priv_value_type type;
> +		union {
> +			u64 val;
> +		};
> +	} value;
> +};
> +

... because this structure holds only one config term.

In next version I'd like to save multiple setting operations in
this structure.

Thank you.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/