Refactors the netpoll UDP transmit path to improve code clarity,
maintainability, and protocol-layer encapsulation.

Function netpoll_send_udp() has more than 100 LoC, which is hard to
understand and review. After this patchset, it has only 32 LoC, which is
more manageable.

The series systematically moves the construction of protocol headers
(UDP, IPv4, IPv6, Ethernet) out of the core `netpoll_send_udp()`
function into dedicated static helpers:

  - `push_udp()` for UDP header setup
  - `push_ipv4()` and `push_ipv6()` for IP header setup
  - `push_eth()` for Ethernet header setup

This results in a clean, layered abstraction that mirrors the protocol
stack, reduces code duplication, and improves readability.

Also, to make sure this is not breaking anything, add IPv6 selftest to
netconsole tests, which will exercise this code. This test would also pick
problems similiar to the one fixed by f599020702698  ("net: netpoll:
Initialize UDP checksum field before checksumming"), which was
embarrassin we didn't have a selftest catch it.

Anyway, there are **no functional changes** intended in this patchset.

Signed-off-by: Breno Leitao <lei...@debian.org>
---
Breno Leitao (7):
      netpoll: Improve code clarity with explicit struct size calculations
      netpoll: factor out UDP checksum calculation into helper
      netpoll: factor out IPv6 header setup into push_ipv6() helper
      netpoll: factor out IPv4 header setup into push_ipv4() helper
      netpoll: factor out UDP header setup into push_udp() helper
      netpoll: move Ethernet setup to push_eth() helper
      selftests: net: Add IPv6 support to netconsole basic tests

 net/core/netpoll.c                                 | 196 +++++++++++++--------
 .../selftests/drivers/net/lib/sh/lib_netcons.sh    |  74 +++++++-
 .../testing/selftests/drivers/net/netcons_basic.sh |  52 +++---
 3 files changed, 216 insertions(+), 106 deletions(-)
---
base-commit: 8efa26fcbf8a7f783fd1ce7dd2a409e9b7758df0
change-id: 20250620-netpoll_untagle_ip-e37c799a6925

Best regards,
--  
Breno Leitao <lei...@debian.org>


Reply via email to