[dpdk-dev] [PATCH v4 6/6] net/iavf: add watchdog for VFLR

[Nicolau, Radu]

On 10/4/2021 12:18 PM, Nicolau, Radu wrote:
>
> On 10/4/2021 3:15 AM, Wu, Jingjing wrote:
>>
>>> -----Original Message-----
>>> From: Nicolau, Radu <radu.nicolau at intel.com>
>>> Sent: Friday, October 1, 2021 5:52 PM
>>> To: Wu, Jingjing <jingjing.wu at intel.com>; Xing, Beilei 
>>> <beilei.xing at intel.com>
>>> Cc: dev at dpdk.org; Doherty, Declan <declan.doherty at intel.com>; Sinha, 
>>> Abhijit
>>> <abhijit.sinha at intel.com>; Zhang, Qi Z <qi.z.zhang at intel.com>; 
>>> Richardson, Bruce
>>> <bruce.richardson at intel.com>; Ananyev, Konstantin 
>>> <konstantin.ananyev at intel.com>;
>>> Nicolau, Radu <radu.nicolau at intel.com>
>>> Subject: [PATCH v4 6/6] net/iavf: add watchdog for VFLR
>>>
>>> Add watchdog to iAVF PMD which support monitoring the VFLR register. If
>>> the device is not already in reset then if a VF reset in progress is
>>> detected then notfiy user through callback and set into reset state.
>>> If the device is already in reset then poll for completion of reset.
>>>
>>> Signed-off-by: Declan Doherty <declan.doherty at intel.com>
>>> Signed-off-by: Radu Nicolau <radu.nicolau at intel.com>
>>> ---
>>>   drivers/net/iavf/iavf.h        |  6 +++
>>>   drivers/net/iavf/iavf_ethdev.c | 97 
>>> ++++++++++++++++++++++++++++++++++
>>>   2 files changed, 103 insertions(+)
>>>
>>> ...
>>>
>> Besides checking VFGEN_RSTAT, there is a process to handle 
>> VIRTCHNL_OP_EVENT  from PF. What is the change for? Any scenario 
>> which VIRTCHNL_OP_EVENT  doesn't cover?
>> And how is the 500us been determined?
>
> Hi Jingjing, thanks for reviewing, I think this can be handled with 
> the VIRTCHNL_OP_EVENT  with no need for a watchdog alarm, I will 
> rework the patch.
>
Hi Jingjing I went over this with Declan, the reason it was added is 
that we can actually have a hardware initiated reset that may not 
trigger an event; and also the kernel driver is implementing a similar 
mechanism. The 500us seems indeed excessive I will update the patch to 
use a configurable value with the default of 5ms, as the kernel driver does.