netdev - Re: [PATCH net-next] lib: Allow for the DIM library to be modular

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: Thu, 2 May 2024 20:19:27 -0700
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Jakub Kicinski <kuba@...nel.org>, Heng Qi <hengqi@...ux.alibaba.com>
Cc: netdev@...r.kernel.org, jgg@...dia.com, leonro@...dia.com,
 Andrew Morton <akpm@...ux-foundation.org>, Tal Gilboa <talgi@...dia.com>,
 "open list:LIBRARY CODE" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next] lib: Allow for the DIM library to be modular

+CC Heng,

On 5/2/2024 5:58 PM, Jakub Kicinski wrote:
> On Thu,  2 May 2024 17:25:40 -0700 Florian Fainelli wrote:
>> Allow the Dynamic Interrupt Moderation (DIM) library to be built as a
>> module. This is particularly useful in an Android GKI (Google Kernel
>> Image) configuration where everything is built as a module, including
>> Ethernet controller drivers. Having to build DIMLIB into the kernel
>> image with potentially no user is wasteful.
> 
> How big is it? Folks from Alibaba are trying to add the ability to
> change the profiles, they'd need to change the calling conventions.
> Which is not terrible, but also why make them suffer if the gain
> isn't big..

It is not too big (16KB as a module), however the issue is more 
logistical than the overall size of the kernel image (although that 
might be a concern, too).

The GKI default configuration would have to enable CONFIG_DIMLIB=y 
regardless of whether a driver makes use of it. They would not enable 
any hardware specific modules (e.g.: CONFIG_BCMGENET=m, CONFIG_STMMAC=m) 
in their configuration that is not common to a large number of 
platforms. So the result is that you end up with code being built-in 
that is potentially not used, and you may not have visibility into its 
usage because the model makes it that SoC vendors can built their 
modules against the GKI configuration. Arguably we can solve that within 
our "overlay" at the source level, but I would rather maintain as fewer 
patches as possible and it does not take away anything IMHO.

Looking at "[PATCH net-next v11 0/4] ethtool: provide the dim profile 
fine-tuning channel" it seems like Heng took care of making all of the 
newly added functions EXPORT_SYMBOL(). The only thing I see missing is a 
"select DIMLIB" from config ETHTOOL_NETLINK, do you see something else?
-- 
Florian

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4221 bytes)