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] [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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ