Re: [PATCH net-next v3 12/14] octeontx2-pf: ipsec: Process CPT metapackets
From: Simon Horman <horms@kernel.org>
Date: 2025-07-12 13:39:53
Also in:
linux-crypto
On Fri, Jul 11, 2025 at 05:43:05PM +0530, Tanmay Jagdale wrote:
CPT hardware forwards decrypted IPsec packets to NIX via the X2P bus as metapackets which are of 256 bytes in length. Each metapacket contains CPT_PARSE_HDR_S and initial bytes of the decrypted packet that helps NIX RX in classifying and submitting to CPU. Additionally, CPT also sets BIT(11) of the channel number to indicate that it's a 2nd pass packet from CPT. Since the metapackets are not complete packets, they don't have to go through L3/L4 layer length and checksum verification so these are disabled via the NIX_LF_INLINE_RQ_CFG mailbox during IPsec initialization. The CPT_PARSE_HDR_S contains a WQE pointer to the complete decrypted packet. Add code in the rx NAPI handler to parse the header and extract WQE pointer. Later, use this WQE pointer to construct the skb, set the XFRM packet mode flags to indicate successful decryption before submitting it to the network stack. Signed-off-by: Tanmay Jagdale <redacted> --- Changes in V3: - Updated cpt_parse_hdr_s structure to use __be64 type
...
quoted hunk ↗ jump to hunk
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k_ipsec.h b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k_ipsec.h
...
quoted hunk ↗ jump to hunk
@@ -302,6 +303,41 @@ struct cpt_sg_s { u64 rsvd_63_50 : 14; }; +/* CPT Parse Header Structure for Inbound packets */ +struct cpt_parse_hdr_s { + /* Word 0 */ + __be64 pkt_out : 2; + __be64 num_frags : 3; + __be64 pad_len : 3; + __be64 pkt_fmt : 1; + __be64 et_owr : 1; + __be64 reserved_53 : 1; + __be64 reas_sts : 4; + __be64 err_sum : 1; + __be64 match_id : 16; + __be64 cookie : 32; + + /* Word 1 */ + __be64 wqe_ptr; + + /* Word 2 */ + __be64 fi_offset : 5; + __be64 fi_pad : 3; + __be64 il3_off : 8; + __be64 pf_func : 16; + __be64 res_32_16 : 16; + __be64 frag_age : 16; + + /* Word 3 */ + __be64 spi : 32; + __be64 res3_32_16 : 16; + __be64 uc_ccode : 8; + __be64 hw_ccode : 8;
Sparse complains about this and I'm not at all sure how __be64 bitfields function on little endian systems. I'd suggest using u64 members (not bitfields) and a combination of FIELD_GET/FIELD_PREP, BITULL/GENMASK_ULL, and cpu_from_be64/be64_from_cpu.
+ + /* Word 4 */ + __be64 misc; +}; +
... -- pw-bot: changes-requested