> -----Original Message-----
> From: Ferruh Yigit <ferruh.yi...@intel.com>
> Sent: Thursday, June 6, 2019 9:49 PM
> To: Jerin Jacob Kollanukkaran <jer...@marvell.com>; dev@dpdk.org; Nithin
> Kumar Dabilpuram <ndabilpu...@marvell.com>; Kiran Kumar Kokkilagadda
> <kirankum...@marvell.com>
> Cc: Vivek Kumar Sharma <viveksha...@marvell.com>
> Subject: Re: [EXT] Re: [dpdk-dev] [PATCH v1 09/58] net/octeontx2: add
> context debug utils
>
> On 6/6/2019 5:04 PM, Jerin Jacob Kollanukkaran wrote:
> >> -----Original Message-----
> >> From: Ferruh Yigit <ferruh.yi...@intel.com>
> >> Sent: Thursday, June 6, 2019 9:12 PM
> >> To: Jerin Jacob Kollanukkaran <jer...@marvell.com>; dev@dpdk.org;
> >> Nithin Kumar Dabilpuram <ndabilpu...@marvell.com>; Kiran Kumar
> >> Kokkilagadda <kirankum...@marvell.com>
> >> Cc: Vivek Kumar Sharma <viveksha...@marvell.com>
> >> Subject: [EXT] Re: [dpdk-dev] [PATCH v1 09/58] net/octeontx2: add
> >> context debug utils On 6/2/2019 4:23 PM, jer...@marvell.com wrote:
> >>> From: Jerin Jacob <jer...@marvell.com>
> >>>
> >>> Add RQ,SQ,CQ context and CQE structure dump utils.
> >>>
> >>> Signed-off-by: Jerin Jacob <jer...@marvell.com>
> >>> Signed-off-by: Vivek Sharma <viveksha...@marvell.com>
> >>
> >> <...>
> >>
> >>> @@ -23,6 +23,9 @@ nix_lf_err_irq(void *param)
> >>>
> >>> /* Clear interrupt */
> >>> otx2_write64(intr, dev->base + NIX_LF_ERR_INT);
> >>> +
> >>> + otx2_nix_queues_ctx_dump(eth_dev);
> >>> + rte_panic("nix_lf_error_interrupt\n");
> >>> }
> >>>
> >>> static int
> >>> @@ -75,6 +78,9 @@ nix_lf_ras_irq(void *param)
> >>>
> >>> /* Clear interrupt */
> >>> otx2_write64(intr, dev->base + NIX_LF_RAS);
> >>> +
> >>> + otx2_nix_queues_ctx_dump(eth_dev);
> >>> + rte_panic("nix_lf_ras_interrupt\n");
> >>> }
> >>>
> >>> static int
> >>> @@ -232,6 +238,9 @@ nix_lf_q_irq(void *param)
> >>>
> >>> /* Clear interrupt */
> >>> otx2_write64(intr, dev->base + NIX_LF_QINTX_INT(qintx));
> >>> +
> >>> + otx2_nix_queues_ctx_dump(eth_dev);
> >>> + rte_panic("nix_lf_q_interrupt\n");
> >>
> >> rte_panic() is not allowed in the PMDs, please remove them.
> >
> > It an error interrupt handler ie. fatal error and driver can not proceed.
> > Should I call abort() or simply return ? I think, we can treat this as
> > a special case for rte_panic() if it is in error interrupt handler.
> >
> > Thoughts?
>
> Driver may not proceed but perhaps application may, (with a fail-over
> method etc ... ) a driver shouldn't cause application to exit, app itself
> should
> give the decision.
OK. I will remove the rte_panic().
>
> I think best thing to do is, deactivate the driver and send some kind of error
> to the application.
>
