Re: [PATCH net-next] octeontx2-pf: Add NIXLF error and poison interrupt handlers

On Wed, Aug 12, 2026 at 09:36:26PM +0530, [email protected] wrote:
> From: Naveen Mamindlapalli <[email protected]>
> 
> Register and handle the NIX LF error (NIX_LF_ERR_INT) and poison/RAS
> (NIX_LF_RAS) interrupt vectors, The handlers acknowledge the interrupt
> and log the status (ratelimited) to help debug NIX LF faults.
> 
> Signed-off-by: Nitin Shetty J <[email protected]>
> Signed-off-by: Naveen Mamindlapalli <[email protected]>

...

> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_vf.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_vf.c
> index b022f52c6845..2a5630561b12 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_vf.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_vf.c
> @@ -554,7 +554,7 @@ static int otx2vf_realloc_msix_vectors(struct otx2_nic *vf)
>  	int num_vec, err;
>  
>  	num_vec = hw->nix_msixoff;
> -	num_vec += NIX_LF_CINT_VEC_START + hw->max_queues;
> +	num_vec += NIX_LF_POISON_VEC + 1;

Hi,

There is an AI-generated review of this patch available at
https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260812160627.3992050-1-nshettyj%40marvell.com

The following part of that review seems of particular note
and I am wondering if you could comment on it.

  Can this fixed vector budget end up smaller than the number of CINT
  vectors the driver actually registers on a VF?

  The new count reserves exactly 64 CINT slots, per otx2_common.h:

	#define NIX_LF_QINT_VEC_START	0x00
	#define NIX_LF_CINT_VEC_START	0x40
	#define NIX_LF_GINT_VEC		0x80
	#define NIX_LF_ERR_VEC		0x81
	#define NIX_LF_POISON_VEC	0x82

  but otx2_open() still walks the CINT vectors from hw->cint_cnt:

	vec = pf->hw.nix_msixoff + NIX_LF_CINT_VEC_START;
	for (qidx = 0; qidx < pf->hw.cint_cnt; qidx++) {
		...
		err = request_irq(pci_irq_vector(pf->pdev, vec),
				  otx2_cq_intr_handler, 0, irq_name,
				  &qset->napi[qidx]);

  For the PF that is bounded, because otx2_probe() clamps:

	qcount = min_t(int, num_online_cpus(), OTX2_MAX_CQ_CNT);

  otx2vf_probe() has no such clamp:

	qcount = num_online_cpus();
	...
	hw->rx_queues = qcount;
	hw->tx_queues = qcount;
	hw->max_queues = qcount;

  so hw->cint_cnt can exceed 64.  With 66 or 67 online CPUs the CQ loop
  claims vector indices 0x81 and 0x82 with dev_id = &qset->napi[qidx] and
  no IRQF_SHARED, so the new request_irq() for NIX_LF_ERR_VEC returns
  -EBUSY and otx2_open() fails through err_free_cints.  With 68 or more
  online CPUs the CQ loop itself fails, since pci_irq_vector() returns
  -EINVAL for indices past the 131 allocated vectors.  With the old
  formula the request grew with hw->max_queues, so both probe and open
  succeeded in those configurations.

  Would something like requesting max(NIX_LF_POISON_VEC + 1,
  NIX_LF_CINT_VEC_START + hw->max_queues), or clamping the VF qcount to
  OTX2_MAX_CQ_CNT the way otx2_probe() does, work here?

  Also, the comment above the PF change now reads oddly:

	/* NPA interrupts are inot registered, so alloc only
	 * upto NIX vector offset.
	 */

>  
>  	otx2vf_disable_mbox_intr(vf);
>  	pci_free_irq_vectors(hw->pdev);
> -- 
> 2.48.1
>