[PATCH v9 03/25] net/ethtool: add ULP_DDP_{GET,SET} operations for caps and stats

[Aurelien Aptel]

Jakub Kicinski <kuba at kernel.org> writes:
> But this is not how they should be carried.
>
> The string set is retrieved by a separate command, then you request
> a string based on the attribute ID (global_stringset() + get_string()
> in ethtool CLI code).
>
> That way long running code or code dumping muliple interfaces can load
> strings once and dumps are kept smaller.

As far as I understand, this is what our code is doing, it is aligned
with the feature bits implementation and its usage of bitsets.

Features use netlink bitsets which have a verbose (include literal
strings) and compact form (use stringset ID).

Similarly our stats have a verbose (literal strings) and compact
form (use implicit stringset ID).

In the compact form, since we always return the complete stats list the
string id is implicit: the first stat is string id 0, next one string id
1, and so on. We just return the complete stat array as a blob under
"COMPACT_VALUES".

In ethtool CLI we are using the compact form and calling
global_stringset() + get_string() as you suggested:

	stat_names = global_stringset(ETH_SS_ULP_DDP_STATS,
				      nlctx->ethnl2_socket);

Then later:

	for (i = 0; i < results.stat_count; i++) {
		const char *name = get_string(stat_names, i);
		printf("%s: %lu\n", name, results.stats[i]);
	}

See
https://github.com/aaptel/ethtool/blob/ulp-ddp-v9/netlink/ulp_ddp.c#L186-L189
https://github.com/aaptel/ethtool/blob/ulp-ddp-v9/netlink/ulp_ddp.c#L154-L157

Should we remove the verbose form?

> ethtool commands mostly talk to HW, note that the feature configuration
> (ethtool -k/-K) does not use ethtool ops either.

Ok, we will move all the ops to netdev->ulp_ddp_ops as suggested.

>> > Why does the ethtool API not expose limits?
>>
>> Originally, and before we started adding the netlink interface, we were
>> not planning to include the ability to modify the limits as part of this
>> series.  We do agree that it now makes sense, but we will add, some
>> limits reflect hardware limitations while other could be tweaked by
>> users.  Those limits will be per-device and per-protocol. We will
>> suggest how to design it.
>
> Alright, I was mostly curious, it's not a requirement for initial
> support.

Ok, thanks.