netdev - Re: Questions about the chelsio/cxgb3 Driver

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: <20240714082256.53fa86b8@kernel.org>
Date: Sun, 14 Jul 2024 08:22:56 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Niigee Mashook <mashookniigee@...il.com>
Cc: Potnuri Bharat Teja <bharat@...lsio.com>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, netdev@...r.kernel.org
Subject: Re: Questions about the chelsio/cxgb3 Driver - TX Stall

On Wed, 10 Jul 2024 21:19:57 +0800 Niigee Mashook wrote:
> 1. Why is not using Tx completion interrupts considered better?
> One reason I can think of is that reducing interrupts to the CPU can
> improve overall performance by allowing the CPU to handle packets more
> efficiently. However, I am concerned that using skb_orphan might cause
> issues like invalidating autocork and leading to bufferbloat(TSQ's
> functionality), which could negatively impact performance. Would this
> not cause a performance regression?

Indeed, this method will have negative effects on any backpressure
mechanism. It's an old driver 🤷️ The perf benefit comes as you say
from fewer IRQs and very good batching.

> 2. The comment specifically mentions skb_orphan, and not using it
> would cause a Tx stall. Why is that?
> My understanding is that when sk->sk_sndbuf is small, it might allow
> only the first packet to be sent. Without skb_orphan, after sending
> the first packet, sk->sk_sndbuf becomes equal to sk_wmem_alloc, which
> would prevent subsequent packets from being sent. As a result,
> sk_wmem_alloc would never decrease, leading to a Tx stall. Is this
> correct?

Yes, pretty much.