Re: [net-next PATCH v1 13/15] octeontx2-pf: ipsec: Manage NPC rules and SPI-to-SA table entries

Tanmay Jagdale
2025-05-22T10:02:27Z

Hi Simon,

On 2025-05-07 at 21:28:14, Simon Horman (horms@kernel.org) wrote:
> On Fri, May 02, 2025 at 06:49:54PM +0530, Tanmay Jagdale wrote:
> > NPC rule for IPsec flows
> > ------------------------
> > Incoming IPsec packets are first classified for hardware fastpath
> > processing in the NPC block. Hence, allocate an MCAM entry in NPC
> > using the MCAM_ALLOC_ENTRY mailbox to add a rule for IPsec flow
> > classification.
> >
> > Then, install an NPC rule at this entry for packet classification
> > based on ESP header and SPI value with match action as UCAST_IPSEC.
> > Also, these packets need to be directed to the dedicated receive
> > queue so provide the RQ index as part of NPC_INSTALL_FLOW mailbox.
> > Add a function to delete NPC rule as well.
> >
> > SPI-to-SA match table
> > ---------------------
> > NIX RX maintains a common hash table for matching the SPI value from
> > in ESP packet to the SA index associated with it. This table has 2K entries
> > with 4 ways. When a packet is received with action as UCAST_IPSEC, NIXRX
> > uses the SPI from the packet header to perform lookup in the SPI-to-SA
> > hash table. This lookup, if successful, returns an SA index that is used
> > by NIXRX to calculate the exact SA context address and programs it in
> > the CPT_INST_S before submitting the packet to CPT for decryption.
> >
> > Add functions to install the delete an entry from this table via the
> > NIX_SPI_TO_SA_ADD and NIX_SPI_TO_SA_DELETE mailbox calls respectively.
> >
> > When the RQs are changed at runtime via ethtool, RVU PF driver frees all
> > the resources and goes through reinitialization with the new set of receive
> > queues. As part of this flow, the UCAST_IPSEC NPC rules that were installed
> > by the RVU PF/VF driver have to be reconfigured with the new RQ index.
> >
> > So, delete the NPC rules when the interface is stopped via otx2_stop().
> > When otx2_open() is called, re-install the NPC flow and re-initialize the
> > SPI-to-SA table for every SA context that was previously installed.
> >
> > Signed-off-by: Tanmay Jagdale <tanmay@marvell.com>
> > ---
> > .../marvell/octeontx2/nic/cn10k_ipsec.c | 201 ++++++++++++++++++
> > .../marvell/octeontx2/nic/cn10k_ipsec.h | 7 +
> > .../ethernet/marvell/octeontx2/nic/otx2_pf.c | 9 +
> > 3 files changed, 217 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k_ipsec.c b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k_ipsec.c
>
> ...
>
> > +static int cn10k_inb_install_flow(struct otx2_nic *pfvf, struct xfrm_state *x,
> > + struct cn10k_inb_sw_ctx_info *inb_ctx_info)
> > +{
> > + struct npc_install_flow_req *req;
> > + int err;
> > +
> > + mutex_lock(&pfvf->mbox.lock);
> > +
> > + req = otx2_mbox_alloc_msg_npc_install_flow(&pfvf->mbox);
> > + if (!req) {
> > + err = -ENOMEM;
> > + goto out;
> > + }
> > +
> > + req->entry = inb_ctx_info->npc_mcam_entry;
> > + req->features |= BIT(NPC_IPPROTO_ESP) | BIT(NPC_IPSEC_SPI) | BIT(NPC_DMAC);
> > + req->intf = NIX_INTF_RX;
> > + req->index = pfvf->ipsec.inb_ipsec_rq;
> > + req->match_id = 0xfeed;
> > + req->channel = pfvf->hw.rx_chan_base;
> > + req->op = NIX_RX_ACTIONOP_UCAST_IPSEC;
> > + req->set_cntr = 1;
> > + req->packet.spi = x->id.spi;
> > + req->mask.spi = 0xffffffff;
>
> I realise that the value is isomorphic, but I would use the following
> so that the rvalue has an endian annotation that matches the lvalue.
>
> req->mask.spi = cpu_to_be32(0xffffffff);
>
> Flagged by Sparse.
ACK.

>
> > +
> > + /* Send message to AF */
> > + err = otx2_sync_mbox_msg(&pfvf->mbox);
> > +out:
> > + mutex_unlock(&pfvf->mbox.lock);
> > + return err;
> > +}
>
> ...
>
> > +static int cn10k_inb_delete_spi_to_sa_match_entry(struct otx2_nic *pfvf,
> > + struct cn10k_inb_sw_ctx_info *inb_ctx_info)
>
> gcc-14.2.0 (at least) complains that cn10k_inb_delete_spi_to_sa_match_entry
> is unused.
Oops.
>
> Likewise for cn10k_inb_delete_flow and cn10k_inb_delete_spi_to_sa_match_entry.
>
> I'm unsure of the best way to address this but it would be nice
> to avoid breaking build bisection for such a trivial reason.
>
> Some ideas:
> * Maybe it is possible to squash this and the last patch,
> or bring part of the last patch into this patch, or otherwise
> rearrange things to avoid this problem.
> * Add temporary __maybe_unusd annotations.
> (I'd consider this a last resort.)
Okay, I'll rearrange the code to avoid this issue.

Thanks,
Tanmay
>
> ...