mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [RFC PATCH net-next 0/4] net: streamline skb_splice_from_iter()
@ 2026-11-10 11:23 Alex Markuze
  2026-11-10 11:23 ` [RFC PATCH net-next 1/4] net: preserve splice iterator progress on rejection Alex Markuze
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: Alex Markuze @ 2026-11-10 11:23 UTC (permalink / raw)
  To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
  Cc: Simon Horman, netdev, linux-kernel

skb_splice_from_iter() does per-page work even when the input describes a
contiguous range of a larger folio. Adjacent tail pages have different page
pointers, so appending them separately also prevents fragment coalescing.
For ITER_BVEC, the helper first builds a page array, then walks it to append
the bytes that the original bvecs already described.

This series removes that redundant work from the MSG_SPLICE_PAGES path
used by sendfile(), splice() and other in-kernel socket senders. Contiguous
folio ranges become fewer skb fragments, with fewer page-reference
operations; BVEC input is consumed directly, without the temporary array.

The patches separate a correctness fix from the optimizations:

  1. Make a zero-byte request a no-op and restore the unappended iterator
     remainder after rejection, preserving any successfully appended prefix.
  2. Group contiguous bytes of a direct-mapped folio, including across
     extraction batches and repeated calls. Representation-safe anchors
     and wide endpoint arithmetic keep offsets and lengths well-defined.
  3. Walk ITER_BVEC segments directly and advance only by appended bytes.
     Bound the request against the unsigned iterator count before assigning
     the result to the signed return type.
  4. Add two KUnit cases for append/resume and zero-length/rejection
     progress, on both the extraction path and the direct BVEC walk.

Grouping stays within a folio and preserves the append helper's ownership
checks. CONFIG_HIGHMEM retains actual-page, in-page-offset, page-bounded
fragments. Software checksum traversal remains page-aware. The caller's
byte-count and partial-progress interface is unchanged.

Performance
-----------

An alternating A/B of the folio-grouping and direct-BVEC implementation
showed lower sender CPU cost for sendfile() from large folios:

  sendfile() workload                         change in sender CPU/GB
  64 KiB folios, 64 KiB transfers, full speed          -11%
  64 KiB folios, 64 KiB transfers, paced at 1 GB/s      -5%
  4 KiB folios, tested transfer/rate combinations      -3% to +3%

At 64 KiB, large-folio sends used about 2 fragments per skb instead of
about 16. Single-page folios retained the per-page layout, providing a
control for the optimization. The large-folio 256 KiB CPU result was within
run-to-run variation, rather than a resolved improvement.

The measurements used a Linux 7.3-rc6-based evaluation kernel (532788178)
and virtio-net VMs, with interrupts pinned to NUMA node 0. Each
cell had four runs per kernel in alternating rounds. CPU/GB is whole-host
sender CPU time, total minus idle, per GB sent; received data was verified.
These measurements cover the earlier implementation of the optimizations.
The present revision adds iterator and representation corner-case fixes
and the regression coverage described below.

Testing
-------

The mailed tests are two KUnit cases, not a broad ownership or coordinate
matrix. Each runs through both the extraction path and the direct BVEC
walk. One appends part of a multi-page folio and resumes: payload,
checksum, fragment count, iterator residual and ordinary references.
The other checks a zero-length no-op and rejected-page rollback with and
without an accepted prefix.

Those cases passed on UML, with no skips. The focused build used W=1 and
WERROR=y. The mails apply to the stated base and match the recorded
intermediate trees. This is not a KASAN run, a physical-NIC test, or a
rerun of the measurement above.

Together, the measured reduction in fragments and sender CPU cost, the
single-page-folio control, and the progress regressions support making
this a generic improvement to skb_splice_from_iter().

Thanks,
Alex Markuze

Alex Markuze (4):
  net: preserve splice iterator progress on rejection
  net: skb_splice_from_iter(): group consecutive pages of a folio
  net: skb_splice_from_iter(): walk ITER_BVEC segments directly
  net: add basic splice KUnit tests

 include/linux/skbuff.h   |   3 +-
 net/core/net_test.c      | 170 +++++++++++++++++++++++++++++++++++++++++++++++
 net/core/skbuff.c        | 141 ++++++++++++++++++++++++++++++++++++---
 net/core/skbuff_splice.h |  34 ++++++++++
 4 files changed, 338 insertions(+), 10 deletions(-)
 create mode 100644 net/core/skbuff_splice.h

base-commit: 4dd16e31135ea8437a720222df34e8745f385d6d


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2026-11-10 11:26 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-10 11:23 [RFC PATCH net-next 0/4] net: streamline skb_splice_from_iter() Alex Markuze
2026-11-10 11:23 ` [RFC PATCH net-next 1/4] net: preserve splice iterator progress on rejection Alex Markuze
2026-11-10 11:23 ` [RFC PATCH net-next 2/4] net: skb_splice_from_iter(): group consecutive pages of a folio Alex Markuze
2026-11-10 11:23 ` [RFC PATCH net-next 3/4] net: skb_splice_from_iter(): walk ITER_BVEC segments directly Alex Markuze
2026-11-10 11:23 ` [RFC PATCH net-next 4/4] net: add basic splice KUnit tests Alex Markuze
2026-11-10 11:26 ` [RFC PATCH net-next 0/4] net: streamline skb_splice_from_iter() netdev-bot+sinfo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®