Hi Simon,

On 2025-07-12 at 19:09:50, Simon Horman (horms@kernel.org) wrote:

On Fri, Jul 11, 2025 at 05:43:05PM +0530, Tanmay Jagdale wrote:

quoted

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

diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k_ipsec.h b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k_ipsec.h

...

quoted

@@ -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.

Okay sure. I will switch to FIELD_GET/PREP mechanism in the next version.

With Regards,
Tanmay

quoted

+
+	/* Word 4 */
+	__be64 misc;
+};
+

...

-- 
pw-bot: changes-requested