linux-kernel - Re: [PATCH RESEND net-next] net: tcp: tsq: Convert from tasklet to BH workqueue

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: <CANn89iLan0LsN2X9RA-PkaQk+6EQJiFL0eCqQ5VsCCyU2r5gFg@mail.gmail.com>
Date: Tue, 10 Jun 2025 07:47:02 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: Tejun Heo <tj@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, 
	David Ahern <dsahern@...nel.org>, Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Jason Xing <kerneljasonxing@...il.com>
Subject: Re: [PATCH RESEND net-next] net: tcp: tsq: Convert from tasklet to BH workqueue

On Mon, Jun 9, 2025 at 1:47 PM Tejun Heo <tj@...nel.org> wrote:
>
> The only generic interface to execute asynchronously in the BH context is
> tasklet; however, it's marked deprecated and has some design flaws. To
> replace tasklets, BH workqueue support was recently added. A BH workqueue
> behaves similarly to regular workqueues except that the queued work items
> are executed in the BH context.
>
> This patch converts TCP Small Queues implementation from tasklet to BH
> workqueue.
>
> Semantically, this is an equivalent conversion and there shouldn't be any
> user-visible behavior changes. While workqueue's queueing and execution
> paths are a bit heavier than tasklet's, unless the work item is being queued
> every packet, the difference hopefully shouldn't matter.

On a 100Gbit NIC and 32 TX queues, I see about 170,000 calls to
tcp_tsq_workfn() when the link is saturated.

Note that a tasklet could only be raised on the local cpu.
Switching to a work queue allows us to start the work on the cpu who
did the last xmit, thus reducing the load on the cpu servicing the NIC
irqs,
a bit like RFS does on the receive path.

I am tempted to say yes to your patch, hopefully we will not regress
if highprio user threads are competing with this work queue.

Reviewed-by: Eric Dumazet <edumazet@...gle.com>