linux-kernel - Re: [PATCH v1 net-next] net: lan743x: configure interrupt moderation timers based on speed

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: <20250508065419.2a089eba@kernel.org>
Date: Thu, 8 May 2025 06:54:19 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: <Thangaraj.S@...rochip.com>
Cc: <Bryan.Whitehead@...rochip.com>, <andrew+netdev@...n.ch>,
 <davem@...emloft.net>, <andrew@...n.ch>, <linux-kernel@...r.kernel.org>,
 <netdev@...r.kernel.org>, <pabeni@...hat.com>, <edumazet@...gle.com>,
 <UNGLinuxDriver@...rochip.com>
Subject: Re: [PATCH v1 net-next] net: lan743x: configure interrupt
 moderation timers based on speed

On Thu, 8 May 2025 03:36:17 +0000 Thangaraj.S@...rochip.com wrote:
> I agree with your comments and will implement the ethtool option to
> provide flexibility, while keeping the default behavior as defined in
> this patch based on speed.

Why the speed based defaults? Do other vendors do that?
330usec is a very high latency, and if the link is running 
at 10M we probably don't need IRQ moderation at all?

For Tx deferring the completion based on link speed makes sense.
We want an IRQ for a fixed amount of data, doesn't matter how 
fast its going out. But for Rx the more aggressive the moderation 
the higher the latency. In my experience the Rx moderation should
not depend on link speed.

reminder: please avoid top posting