[dpdk-dev] [EXT] Re: [PATCH v1 09/58] net/octeontx2: add context debug utils

Ferruh Yigit ferruh.yigit at intel.com
Thu Jun 6 18:18:43 CEST 2019


On 6/6/2019 5:04 PM, Jerin Jacob Kollanukkaran wrote:
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit at intel.com>
>> Sent: Thursday, June 6, 2019 9:12 PM
>> To: Jerin Jacob Kollanukkaran <jerinj at marvell.com>; dev at dpdk.org; Nithin
>> Kumar Dabilpuram <ndabilpuram at marvell.com>; Kiran Kumar Kokkilagadda
>> <kirankumark at marvell.com>
>> Cc: Vivek Kumar Sharma <viveksharma at marvell.com>
>> Subject: [EXT] Re: [dpdk-dev] [PATCH v1 09/58] net/octeontx2: add context
>> debug utils
>> On 6/2/2019 4:23 PM, jerinj at marvell.com wrote:
>>> From: Jerin Jacob <jerinj at marvell.com>
>>>
>>> Add RQ,SQ,CQ context and CQE structure dump utils.
>>>
>>> Signed-off-by: Jerin Jacob <jerinj at marvell.com>
>>> Signed-off-by: Vivek Sharma <viveksharma at 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.

I think best thing to do is, deactivate the driver and send some kind of error
to the application.




More information about the dev mailing list