mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alex Markuze <amarkuze@redhat.com>
To: "David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: Simon Horman <horms@kernel.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC PATCH net-next 0/4] net: streamline skb_splice_from_iter()
Date: Tue, 10 Nov 2026 11:23:21 +0000	[thread overview]
Message-ID: <20261110112325.3263078-1-amarkuze@redhat.com> (raw)

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


             reply	other threads:[~2026-11-10 11:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10 11:23 Alex Markuze [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261110112325.3263078-1-amarkuze@redhat.com \
    --to=amarkuze@redhat.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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®