netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tanmay Jagdale <tanmay@marvell.com>
To: Simon Horman <horms@kernel.org>
Cc: <davem@davemloft.net>, <leon@kernel.org>, <sgoutham@marvell.com>,
	<bbhushan2@marvell.com>, <herbert@gondor.apana.org.au>,
	<linux-crypto@vger.kernel.org>, <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next v2 14/14] octeontx2-pf: ipsec: Add XFRM state and policy hooks for inbound flows
Date: Thu, 10 Jul 2025 14:10:03 +0530	[thread overview]
Message-ID: <aG98Y985la89vYR7@optiplex> (raw)
In-Reply-To: <20250620112249.GL194429@horms.kernel.org>

Hi Simon,

On 2025-06-20 at 16:52:49, Simon Horman (horms@kernel.org) wrote:
> On Wed, Jun 18, 2025 at 05:00:08PM +0530, Tanmay Jagdale wrote:
> > Add XFRM state hook for inbound flows and configure the following:
> >   - Install an NPC rule to classify the 1st pass IPsec packets and
> >     direct them to the dedicated RQ
> >   - Allocate a free entry from the SA table and populate it with the
> >     SA context details based on xfrm state data.
> >   - Create a mapping of the SPI value to the SA table index. This is
> >     used by NIXRX to calculate the exact SA context  pointer address
> >     based on the SPI in the packet.
> >   - Prepare the CPT SA context to decrypt buffer in place and the
> >     write it the CPT hardware via LMT operation.
> >   - When the XFRM state is deleted, clear this SA in CPT hardware.
> > 
> > Also add XFRM Policy hooks to allow successful offload of inbound
> > PACKET_MODE.
> > 
> > Signed-off-by: Tanmay Jagdale <tanmay@marvell.com>
> 
> ...
> 
> > @@ -1141,6 +1154,137 @@ static int cn10k_outb_write_sa(struct otx2_nic *pf, struct qmem *sa_info)
> >  	return ret;
> >  }
> >  
> > +static int cn10k_inb_write_sa(struct otx2_nic *pf,
> > +			      struct xfrm_state *x,
> > +			      struct cn10k_inb_sw_ctx_info *inb_ctx_info)
> > +{
> > +	dma_addr_t res_iova, dptr_iova, sa_iova;
> > +	struct cn10k_rx_sa_s *sa_dptr, *sa_cptr;
> > +	struct cpt_inst_s inst;
> > +	u32 sa_size, off;
> > +	struct cpt_res_s *res;
> > +	u64 reg_val;
> > +	int ret;
> > +
> > +	res = dma_alloc_coherent(pf->dev, sizeof(struct cpt_res_s),
> > +				 &res_iova, GFP_ATOMIC);
> > +	if (!res)
> > +		return -ENOMEM;
> > +
> > +	sa_cptr = inb_ctx_info->sa_entry;
> > +	sa_iova = inb_ctx_info->sa_iova;
> > +	sa_size = sizeof(struct cn10k_rx_sa_s);
> > +
> > +	sa_dptr = dma_alloc_coherent(pf->dev, sa_size, &dptr_iova, GFP_ATOMIC);
> > +	if (!sa_dptr) {
> > +		dma_free_coherent(pf->dev, sizeof(struct cpt_res_s), res,
> > +				  res_iova);
> > +		return -ENOMEM;
> > +	}
> > +
> > +	for (off = 0; off < (sa_size / 8); off++)
> > +		*((u64 *)sa_dptr + off) = cpu_to_be64(*((u64 *)sa_cptr + off));
> > +
> > +	memset(&inst, 0, sizeof(struct cpt_inst_s));
> > +
> > +	res->compcode = 0;
> > +	inst.res_addr = res_iova;
> > +	inst.dptr = (u64)dptr_iova;
> > +	inst.param2 = sa_size >> 3;
> > +	inst.dlen = sa_size;
> > +	inst.opcode_major = CN10K_IPSEC_MAJOR_OP_WRITE_SA;
> > +	inst.opcode_minor = CN10K_IPSEC_MINOR_OP_WRITE_SA;
> > +	inst.cptr = sa_iova;
> > +	inst.ctx_val = 1;
> > +	inst.egrp = CN10K_DEF_CPT_IPSEC_EGRP;
> > +
> > +	/* Re-use Outbound CPT LF to install Ingress SAs as well because
> > +	 * the driver does not own the ingress CPT LF.
> > +	 */
> > +	pf->ipsec.io_addr = (__force u64)otx2_get_regaddr(pf, CN10K_CPT_LF_NQX(0));
> > +	cn10k_cpt_inst_flush(pf, &inst, sizeof(struct cpt_inst_s));
> > +	dmb(sy);
> 
> Hi Tanmay,
> 
> As I understand things the above effectively means that this
> driver will only compile for ARM64.
> 
> I do understand that the driver is only intended to be used on ARM64.
> But it is nice to get compile coverage on other 64bit systems,
> in particular x86_64.
> 
> And moreover, I think the guiding principle should be for drivers
> to be as independent of the host system as possible.
> 
> Can we look into handling this a different way?
ACK, I will use dma_wmb() here so that it is generic.

With Regards,
Tanmay

  reply	other threads:[~2025-07-10  8:40 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-18 11:29 [PATCH net-next v2 00/14] Enable Inbound IPsec offload on Marvell CN10K SoC Tanmay Jagdale
2025-06-18 11:29 ` [PATCH net-next v2 01/14] crypto: octeontx2: Share engine group info with AF driver Tanmay Jagdale
2025-06-18 11:29 ` [PATCH net-next v2 02/14] octeontx2-af: Configure crypto hardware for inline ipsec Tanmay Jagdale
2025-06-18 11:29 ` [PATCH net-next v2 03/14] octeontx2-af: Setup Large Memory Transaction for crypto Tanmay Jagdale
2025-06-18 11:29 ` [PATCH net-next v2 04/14] octeontx2-af: Handle inbound inline ipsec config in AF Tanmay Jagdale
2025-06-18 11:29 ` [PATCH net-next v2 05/14] octeontx2-af: Add support for CPT second pass Tanmay Jagdale
2025-06-20 10:55   ` Simon Horman
2025-06-23  6:48     ` Tanmay Jagdale
2025-06-18 11:30 ` [PATCH net-next v2 06/14] octeontx2-af: Add support for SPI to SA index translation Tanmay Jagdale
2025-06-19 14:37   ` kernel test robot
2025-06-18 11:30 ` [PATCH net-next v2 07/14] octeontx2-af: Add mbox to alloc/free BPIDs Tanmay Jagdale
2025-06-18 11:30 ` [PATCH net-next v2 08/14] octeontx2-pf: ipsec: Allocate Ingress SA table Tanmay Jagdale
2025-06-18 11:30 ` [PATCH net-next v2 09/14] octeontx2-pf: ipsec: Setup NIX HW resources for inbound flows Tanmay Jagdale
2025-06-18 11:30 ` [PATCH net-next v2 10/14] octeontx2-pf: ipsec: Handle NPA threshold interrupt Tanmay Jagdale
2025-06-20 11:00   ` Simon Horman
2025-07-10  8:42     ` Tanmay Jagdale
2025-06-18 11:30 ` [PATCH net-next v2 11/14] octeontx2-pf: ipsec: Initialize ingress IPsec Tanmay Jagdale
2025-06-18 11:30 ` [PATCH net-next v2 12/14] octeontx2-pf: ipsec: Process CPT metapackets Tanmay Jagdale
2025-06-20 11:06   ` Simon Horman
2025-07-10  8:44     ` Tanmay Jagdale
2025-06-18 11:30 ` [PATCH net-next v2 13/14] octeontx2-pf: ipsec: Manage NPC rules and SPI-to-SA table entries Tanmay Jagdale
2025-06-19 23:19   ` kernel test robot
2025-06-18 11:30 ` [PATCH net-next v2 14/14] octeontx2-pf: ipsec: Add XFRM state and policy hooks for inbound flows Tanmay Jagdale
2025-06-20 11:22   ` Simon Horman
2025-07-10  8:40     ` Tanmay Jagdale [this message]
2025-06-25 14:38   ` kernel test robot

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=aG98Y985la89vYR7@optiplex \
    --to=tanmay@marvell.com \
    --cc=bbhushan2@marvell.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=horms@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sgoutham@marvell.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).