[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240712025125.1926249-4-yumike@google.com>
Date: Fri, 12 Jul 2024 10:51:24 +0800
From: Mike Yu <yumike@...gle.com>
To: netdev@...r.kernel.org, steffen.klassert@...unet.com
Cc: stanleyjhu@...gle.com, martinwu@...gle.com, chiachangwang@...gle.com,
yumike@...gle.com
Subject: [PATCH ipsec-next v4 3/4] xfrm: Support crypto offload for inbound
IPv4 UDP-encapsulated ESP packet
If xfrm_input() is called with UDP_ENCAP_ESPINUDP, the packet is
already processed in UDP layer that removes the UDP header.
Therefore, there should be no much difference to treat it as an
ESP packet in the XFRM stack.
Test: Enabled dir=in IPsec crypto offload, and verified IPv4
UDP-encapsulated ESP packets on both wifi/cellular network
Signed-off-by: Mike Yu <yumike@...gle.com>
---
net/xfrm/xfrm_input.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index ba8deb0235ba..7cee9c0a2cdc 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -471,7 +471,8 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
struct xfrm_offload *xo = xfrm_offload(skb);
struct sec_path *sp;
- if (encap_type < 0 || (xo && (xo->flags & XFRM_GRO || encap_type == 0))) {
+ if (encap_type < 0 || (xo && (xo->flags & XFRM_GRO || encap_type == 0 ||
+ encap_type == UDP_ENCAP_ESPINUDP))) {
x = xfrm_input_state(skb);
if (unlikely(x->dir && x->dir != XFRM_SA_DIR_IN)) {
--
2.45.2.993.g49e7a77208-goog
Powered by blists - more mailing lists