netdev - Re: [PATCH net-next v5 4/4] virtio-net: support dim profile fine-tuning

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]

Message-ID: <1cd6cd7d-5cf2-4f86-b084-6e88b0cbf229@linux.alibaba.com>
Date: Wed, 10 Apr 2024 11:09:16 +0800
From: Heng Qi <hengqi@...ux.alibaba.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, virtualization@...ts.linux.dev,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Paolo Abeni <pabeni@...hat.com>, Jason Wang <jasowang@...hat.com>,
 "Michael S. Tsirkin" <mst@...hat.com>,
 Ratheesh Kannoth <rkannoth@...vell.com>,
 Alexander Lobakin <aleksander.lobakin@...el.com>,
 Xuan Zhuo <xuanzhuo@...ux.alibaba.com>
Subject: Re: [PATCH net-next v5 4/4] virtio-net: support dim profile
 fine-tuning

在 2024/4/10 上午9:40, Jakub Kicinski 写道:
> On Tue,  9 Apr 2024 20:03:24 +0800 Heng Qi wrote:
>> +	/* DIM profile list */
>> +	struct dim_cq_moder rx_eqe_conf[NET_DIM_PARAMS_NUM_PROFILES];
> Can you please wrap this into a structure with other necessary
> information and add a pointer in struct net_device instead.
>
> What's the point of every single driver implementing the same
> boilerplate memcpy() in its get_coalesce / set_coalesce callbacks?

The point is that the driver may check whether the user has set 
parameters that it does not want.
For example, virtio may not want the modification of comps, and ice/idpf 
may not want the modification
of comps and pkts.

But you inspired me to think from another perspective. If parameters are 
placed in netdevice, the
goal of user modification is to modify the profile of netdevice, and the 
driver can obtain its own
target parameters from it as needed. Do you like this?

In addition, if the netdevice way is preferred, I would like to confirm 
whether we still continue the
"ethtool -C" way, that is, complete the modification of netdevice 
profile in __ethnl_set_coalesce()?

Thanks.