[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200320095934.GH11304@nanopsycho.orion>
Date: Fri, 20 Mar 2020 10:59:34 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: David Ahern <dsahern@...il.com>
Cc: netdev@...r.kernel.org, stephen@...workplumber.org,
mlxsw@...lanox.com
Subject: Re: [patch iproute2/net-next v5] tc: m_action: introduce support for
hw stats type
Fri, Mar 20, 2020 at 12:56:08AM CET, dsahern@...il.com wrote:
>On 3/14/20 3:25 AM, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@...lanox.com>
>>
>> Introduce support for per-action hw stats type config.
>>
>> This patch allows user to specify one of the following types of HW
>> stats for added action:
>> immediate - queried during dump time
>> delayed - polled from HW periodically or sent by HW in async manner
>> disabled - no stats needed
>>
>> Note that if "hw_stats" option is not passed, user does not care about
>> the type, just expects any type of stats.
>>
>> Examples:
>> $ tc filter add dev enp0s16np28 ingress proto ip handle 1 pref 1 flower skip_sw dst_ip 192.168.1.1 action drop hw_stats disabled
>
>...
>
>> @@ -149,6 +150,59 @@ new_cmd(char **argv)
>> (matches(*argv, "add") == 0);
>> }
>>
>> +static const struct hw_stats_type_item {
>> + const char *str;
>> + __u8 type;
>> +} hw_stats_type_items[] = {
>> + { "immediate", TCA_ACT_HW_STATS_TYPE_IMMEDIATE },
>> + { "delayed", TCA_ACT_HW_STATS_TYPE_DELAYED },
>> + { "disabled", 0 }, /* no bit set */
>> +};
>> +
>> +static void print_hw_stats(const struct rtattr *arg)
>> +{
>> + struct nla_bitfield32 *hw_stats_type_bf = RTA_DATA(arg);
>> + __u8 hw_stats_type;
>> + int i;
>> +
>> + hw_stats_type = hw_stats_type_bf->value & hw_stats_type_bf->selector;
>> + print_string(PRINT_FP, NULL, "\t", NULL);
>> + open_json_array(PRINT_ANY, "hw_stats");
>
>I still do not understand how the type can be multiple. The command line
>is an 'or' : immediate, delayed, or disabled. Further, the filter is
The cmd line is "or". The uapi is bitfield as requested by kernel
reviewers. I originally had that as "or" too.
>added to a specific device which has a single driver. Seems like at
Nope, may be multiple drivers if the block is shared.
>install / config time the user is explicitly stating a single type.
Basically using tc with this patch, you cannot achieve to have multiple
values in this output. However, in general. It could be.
Also, I wanted to have this as array because when I introduce the "used
hw stats" which would indicate which type is actually used (in case you
pass any for example), there might be multiple values, when offloaded to
multiple drivers.
Powered by blists - more mailing lists