Nit: typo in subject ("secion").
2020-01-07 14:03 UTC+0100 ~ Michal Rostecki <mrostecki@xxxxxxxxxxxx>
> Introduce a new probe section (misc) for probes not related to concrete
> map types, program types, functions or kernel configuration. Introduce a
> probe for large INSN limit as the first one in that section.
>
> Signed-off-by: Michal Rostecki <mrostecki@xxxxxxxxxxxx>
> ---
> tools/bpf/bpftool/feature.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/tools/bpf/bpftool/feature.c b/tools/bpf/bpftool/feature.c
> index 03bdc5b3ac49..d8ce93092c45 100644
> --- a/tools/bpf/bpftool/feature.c
> +++ b/tools/bpf/bpftool/feature.c
> @@ -572,6 +572,18 @@ probe_helpers_for_progtype(enum bpf_prog_type prog_type, bool supported_type,
> printf("\n");
> }
>
> +static void
> +probe_large_insn_limit(const char *define_prefix, __u32 ifindex)
> +{
> + bool res;
> +
> + res = bpf_probe_large_insn_limit(ifindex);
> + print_bool_feature("have_large_insn_limit",
> + "Large complexity and program size limit",
I am not sure we should mention "complexity" here. Although it is
related to program size in the kernel commit you describe, the probe
that is run is only on instruction number. This can make a difference
for offloaded programs: When you probe a device, if kernel has commit
c04c0d2b968a and supports up to 1M instructions, but hardware supports
no more than 4k instructions, you may still benefit from the new value
for BPF_COMPLEXITY_LIMIT_INSNS for complexity, but not for the total
number of available instructions. In that case the probe will fail, and
the message on complexity would not be accurate.
Looks good otherwise, thanks Michal!
Quentin
