Hi,

This series reworks how ovpn turns GSO input into encrypted UDP GSO
aggregates. It builds on two series still under review, which are its
prerequisites:

- ovpn: preserve GSO batching (v5)
  https://lore.kernel.org/openvpn-devel/[email protected]/
- ovpn: construct and process GRO batches (v3)
  https://lore.kernel.org/openvpn-devel/[email protected]/

So far, a GSO skb is segmented in software, which also computes every
segment's L4 checksum, and each segment is then encrypted out of place
into the aggregate. Patch 4 instead copies each segment into its final
position in the aggregate, computes the checksum during that copy and
encrypts the record in place. This replaces the out-of-place AEAD path,
so in-place encryption becomes the only UDP GSO encryption path. Patch 5
then skips the child skbs altogether for TCP and UDP GSO input which
tso_build_hdr supports: each record's payload is copied straight from
the original skb, and its headers are synthesized in front of it.
Patches 2 and 3 prepare for this without functional change, moving the
batching code to gso.c and letting it work on a generic record source.

Patch 1 adds a small helper to include/net/tso.h and needs review from
the net core maintainers when the series is forwarded to netdev.

Performance was measured with one TCP flow over UDP ovpn with
AES-128-GCM, a 1408-byte tunnel MTU and a 1500-byte physical MTU between
two directly connected mlx5 ports. Unlike the GSO series, iperf3 used
plain send instead of sendfile (-Z), whose shared page-cache frags make
the segmenter linearize every segment and would overstate the gain. The
sender, the receiver and their interrupts were pinned to separate CPUs.
Each 70-second run omitted the first 10 seconds, with a 15-second perf
sample. Three runs per direction were interleaved, and the values below
are averaged over both directions:

                         Before patch 4   After patch 4   After patch 5
Throughput (Gbit/s)          27.31            29.22           30.32
Sender cycles per byte        1.762            1.614           1.193
Sender instructions/byte      4.450            4.349           3.155

The sender saves about 32% of its cycles per byte over the whole series.
>From patch 4 on, the receiver is the bottleneck and hides most of that
in the throughput. With tx-udp-segmentation disabled on the lower
device, the sender is the bottleneck throughout, and throughput rises
from 17.27 to 17.96 Gbit/s with patch 4 and to 21.72 Gbit/s with patch
5 (+26%).

Without any CPU or IRQ pinning, the series still saves 16% of all
cycles per byte on the host for one flow, receiver included, and 12-13%
with four parallel flows. The four flows share one outer UDP tuple, and
thus one receive queue, so their throughput hardly changes.

Thanks,

Ralf Lici
Mandelbit Srl

Ralf Lici (5):
  net: tso: advance header state independently of the data cursor
  ovpn: move UDP GSO transmit batching to gso.c
  ovpn: batch GSO records from a generic source
  ovpn: encrypt GSO segments in place
  ovpn: encrypt GSO input without child skbs

 drivers/net/ovpn/Makefile      |   1 +
 drivers/net/ovpn/crypto_aead.c | 117 ++----
 drivers/net/ovpn/crypto_aead.h |  15 +-
 drivers/net/ovpn/gso.c         | 666 +++++++++++++++++++++++++++++++++
 drivers/net/ovpn/gso.h         |  21 ++
 drivers/net/ovpn/io.c          | 289 +++-----------
 drivers/net/ovpn/io.h          |   6 +
 include/net/tso.h              |  15 +
 net/core/tso.c                 |   2 +-
 9 files changed, 791 insertions(+), 341 deletions(-)
 create mode 100644 drivers/net/ovpn/gso.c
 create mode 100644 drivers/net/ovpn/gso.h


base-commit: 7b6ab4dbc156e2f96419715130b3d5738a306c93
prerequisite-message-id: [email protected]
prerequisite-message-id: [email protected]
prerequisite-patch-id: 0cc7597aca91a5984596d971b1b066ad6616c329
prerequisite-patch-id: 7a0446fa01fe78fa5f15ddac7a2b9aedda5018a9
prerequisite-patch-id: 15f724fc646c95ebcd83d22d6a8a2e29237a2f1c
prerequisite-patch-id: 257a9b0fe2bdc44fdff6a91f23bfc6306dd86f23
prerequisite-patch-id: 606b9d70ab683614f73f54ed006b05895ac7f0a8
prerequisite-patch-id: 54225ba7c226f8c804b1158a1d9d9e6ae7eaacdb
prerequisite-patch-id: 083ec87dd028ff34a7e84c04ebd4131e366450b0
prerequisite-patch-id: 09240d50ebf50cbba22a692983d36d8d5bf36280
prerequisite-patch-id: 7142b7587fb766e67d27f6158b0cf8bc2e6067f2
prerequisite-patch-id: 234e55c4cfc35cf9a600b1562337b454877a2479
prerequisite-patch-id: 38a6d5a48ae513c991e6c58ccb9baddb6c3f0f88
prerequisite-patch-id: 422293876a77bf7979b0ba8c81b5c7ac3e00bd82
prerequisite-patch-id: 1129c8986ffbad2d485392c6775daecadd230bce
prerequisite-patch-id: 96ee1b0fe6cde46671ee16887ff39b7ed04a89a3
prerequisite-patch-id: d304d8c678e79b6ab9623a9d541839ec9f5e7959
-- 
2.56.0



_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to