netdev - [PATCH v4 net-next 0/4] net: Provide SMP threads for backlog NAPI

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-next>] [day] [month] [year] [list]

Message-ID: <20240305120002.1499223-1-bigeasy@linutronix.de>
Date: Tue,  5 Mar 2024 12:53:18 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: netdev@...r.kernel.org
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>,
	Jesper Dangaard Brouer <hawk@...nel.org>,
	Paolo Abeni <pabeni@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Wander Lairson Costa <wander@...hat.com>,
	Yan Zhai <yan@...udflare.com>
Subject: [PATCH v4 net-next 0/4] net: Provide SMP threads for backlog NAPI

The RPS code and "deferred skb free" both send IPI/ function call
to a remote CPU in which a softirq is raised. This leads to a warning on
PREEMPT_RT because raising softiqrs from function call led to undesired
behaviour in the past. I had duct tape in RT for the "deferred skb free"
and Wander Lairson Costa reported the RPS case.

This series only provides support for SMP threads for backlog NAPI, I
did not attach a patch to make it default and remove the IPI related
code to avoid confusion. I can post it for reference it asked.

The RedHat performance team was so kind to provide some testing here.
The series (with the IPI code removed) has been tested and no regression
vs without the series has been found. For testing iperf3 was used on 25G
interface, provided by mlx5, ix40e or ice driver and RPS was enabled. I
can provide the individual test results if needed.

Changes:
- v3…v4 https://lore.kernel.org/all/20240228121000.526645-1-bigeasy@linutronix.de/

  - Rebase on top of current net-next, collect Acks.

  - Add struct softnet_data as an argument to kick_defer_list_purge().

  - Add sd_has_rps_ipi_waiting() check to napi_threaded_poll_loop() which was
    accidentally removed.

- v2…v3 https://lore.kernel.org/all/20240221172032.78737-1-bigeasy@linutronix.de/

  - Move the "if use_backlog_threads()" case into the CONFIG_RPS block
    within napi_schedule_rps().

  - Use __napi_schedule_irqoff() instead of napi_schedule_rps() in
    kick_defer_list_purge().

- v1…v2 https://lore.kernel.org/all/20230929162121.1822900-1-bigeasy@linutronix.de/

  - Patch #1 is new. It ensures that NAPI_STATE_SCHED_THREADED is always
    set (instead conditional based on task state) and the smboot thread
    logic relies on this bit now. In v1 NAPI_STATE_SCHED was used but is
    racy.

  - The defer list clean up is split out and also relies on
    NAPI_STATE_SCHED_THREADED. This fixes a different race.

- RFC…v1 https://lore.kernel.org/all/20230814093528.117342-1-bigeasy@linutronix.de/

   - Patch #2 has been removed. Removing the warning is still an option.

   - There are two patches in the series:
     - Patch #1 always creates backlog threads
     - Patch #2 creates the backlog threads if requested at boot time,
       mandatory on PREEMPT_RT.
     So it is either or and I wanted to show how both look like.

   - The kernel test robot reported a performance regression with
     loopback (stress-ng --udp X --udp-ops Y) against the RFC version.
     The regression is now avoided by using local-NAPI if backlog
     processing is requested on the local CPU.

Sebastian