在 2024/3/29 上午12:48, Jakub Kicinski 写道:

On Thu, 28 Mar 2024 10:12:10 +0800 Xuan Zhuo wrote:

quoted

For netdim, I think profiles are an aspect. In many cases, this can solve many
problems.

Okay, but then you should try harder to hide all the config in the core.
The driver should be blissfully unaware that the user is changing
the settings. It should just continue calling net_dim_get_*moderation().

You can create proper dim_init(), dim_destroy() functions for drivers
to call, instead of doing

	INIT_WORK(&bla->dim.work, my_driver_do_dim_work);

directly. In dim_init() you can hook the dim structure to net_device
and then ethtool code can operation on it without driver involvement.

Ok. Will try this.

About the uAPI - please make sure you add the new stuff to
Documentation/netlink/specs/ethtool.yaml
see: https://docs.kernel.org/next/userspace-api/netlink/specs.html

And break up the attributes, please, no raw C structs of this nature:

+	return nla_put(skb, attr_type, sizeof(struct dim_cq_moder) *
+		       NET_DIM_PARAMS_NUM_PROFILES, profs);

They are hard to extend.

Sorry, I don't seem to get your point, why does this make extending hard?

Are you referring to specifying ETHTOOL_A_COALESCE_RX_EQE_PROFILE
as a nested array, i.e. having each element explicitly have an attr 
name? or passing the
u16 pointer and length as arguments?

Thanks.