[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 2 Feb 2022 14:53:43 -0700
From: David Ahern <dsahern@...il.com>
To: Paul Chaignon <paul@...valent.com>, netdev@...r.kernel.org
Cc: Stephen Hemminger <stephen@...workplumber.org>,
Hangbin Liu <haliu@...hat.com>
Subject: Re: [PATCH iproute2] lib/bpf: Fix log level in verbose mode with
libbpf
On 2/2/22 2:07 PM, Paul Chaignon wrote:
> On Wed, Feb 02, 2022 at 12:10:03PM -0700, David Ahern wrote:
>> On 2/2/22 11:11 AM, Paul Chaignon wrote:
>>> diff --git a/lib/bpf_libbpf.c b/lib/bpf_libbpf.c
>>> index 50ef16bd..bb6399bf 100644
>>> --- a/lib/bpf_libbpf.c
>>> +++ b/lib/bpf_libbpf.c
>>> @@ -305,7 +305,7 @@ static int load_bpf_object(struct bpf_cfg_in *cfg)
>>>
>>> attr.obj = obj;
>>> if (cfg->verbose)
>>> - attr.log_level = 2;
>>> + attr.log_level = 1;
>>>
>>> ret = bpf_object__load_xattr(&attr);
>>> if (ret)
>>
>> ip and tc do not have verbosity flags, but there is show_details. Why
>> not tie the log_level to that?
>
> I'm not sure I understand what you're proposing. This code is referring
> to the "verbose" parameter of the tc filter command, as in e.g.:
>
> tc filter replace dev eth0 ingress bpf da obj prog.o sec sec1 verbose
>
> Are you proposing we replace that parameter with the existing -details
> option?
>
just proposing that log_level not be hardcoded and coming from the
command line. Connecting with verbose arg makes more sense. How to
extend it to let the user control verbosity
Powered by blists - more mailing lists