On Tue, Jan 07, 2020 at 02:36:15PM +0000, Quentin Monnet wrote:
> 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
Thanks for review! Should I change the description just to "Large
program size limit" or "Large instruction limit"?
Michal
