netdev - Re: [patch iproute2/net-next v5] tc: m_action: introduce support for hw stats type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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.