netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Yu <yumike@google.com>
To: netdev@vger.kernel.org, steffen.klassert@secunet.com
Cc: yumike@google.com, stanleyjhu@google.com, martinwu@google.com,
	 chiachangwang@google.com
Subject: [PATCH ipsec v3 0/4] Support IPsec crypto offload for IPv6 ESP and IPv4 UDP-encapsulated ESP data paths
Date: Wed, 10 Jul 2024 19:16:50 +0800	[thread overview]
Message-ID: <20240710111654.4085575-1-yumike@google.com> (raw)

Currently, IPsec crypto offload is enabled for GRO code path. However, there
are other code paths where the XFRM stack is involved; for example, IPv6 ESP
packets handled by xfrm6_esp_rcv() in ESP layer, and IPv4 UDP-encapsulated
ESP packets handled by udp_rcv() in UDP layer.

This patchset extends the crypto offload support to cover these two cases.
This is useful for devices with traffic accounting (e.g., Android), where GRO
can lead to inaccurate accounting on the underlying network. For example, VPN
traffic might not be counted on the wifi network interface wlan0 if the packets
are handled in GRO code path before entering the network stack for accounting.

Below is the RX data path scenario the crypto offload can be applied to.

  +-----------+   +-------+
  | HW Driver |-->| wlan0 |--------+
  +-----------+   +-------+        |
                                   v
                             +---------------+   +------+
                     +------>| Network Stack |-->| Apps |
                     |       +---------------+   +------+
                     |             |
                     |             v
                 +--------+   +------------+
                 | ipsec1 |<--| XFRM Stack |
                 +--------+   +------------+

v2 -> v3:
- Correct ESP seq in esp_xmit().
v1 -> v2:
- Fix comment style.

Mike Yu (4):
  xfrm: Support crypto offload for inbound IPv6 ESP packets not in GRO
    path
  xfrm: Allow UDP encapsulation in crypto offload control path
  xfrm: Support crypto offload for inbound IPv4 UDP-encapsulated ESP
    packet
  xfrm: Support crypto offload for outbound IPv4 UDP-encapsulated ESP
    packet

 net/ipv4/esp4.c         |  8 +++++++-
 net/ipv4/esp4_offload.c | 17 ++++++++++++++++-
 net/xfrm/xfrm_device.c  |  6 +++---
 net/xfrm/xfrm_input.c   |  3 ++-
 net/xfrm/xfrm_policy.c  |  5 ++++-
 5 files changed, 32 insertions(+), 7 deletions(-)

-- 
2.45.2.803.g4e1b14247a-goog


             reply	other threads:[~2024-07-10 11:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-10 11:16 Mike Yu [this message]
2024-07-10 11:16 ` [PATCH ipsec v3 1/4] xfrm: Support crypto offload for inbound IPv6 ESP packets not in GRO path Mike Yu
2024-07-10 11:16 ` [PATCH ipsec v3 2/4] xfrm: Allow UDP encapsulation in crypto offload control path Mike Yu
2024-07-10 11:16 ` [PATCH ipsec v3 3/4] xfrm: Support crypto offload for inbound IPv4 UDP-encapsulated ESP packet Mike Yu
2024-07-10 11:16 ` [PATCH ipsec v3 4/4] xfrm: Support crypto offload for outbound " Mike Yu
2024-07-11  9:52 ` [PATCH ipsec v3 0/4] Support IPsec crypto offload for IPv6 ESP and IPv4 UDP-encapsulated ESP data paths Leon Romanovsky
2024-07-11 10:11   ` Steffen Klassert
2024-07-12  3:02     ` Mike Yu

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=20240710111654.4085575-1-yumike@google.com \
    --to=yumike@google.com \
    --cc=chiachangwang@google.com \
    --cc=martinwu@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=stanleyjhu@google.com \
    --cc=steffen.klassert@secunet.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;
as well as URLs for NNTP newsgroup(s).