please help backporting some patches to stable release 21.11.9

[Kevin Traynor]

On 29/11/2024 11:32, Richardson, Bruce wrote:
> 
> 
>> -----Original Message-----
>> From: Kevin Traynor <ktraynor at redhat.com>
>> Sent: Friday, November 29, 2024 10:23 AM
>> To: Richardson, Bruce <bruce.richardson at intel.com>; dpdk stable
>> <stable at dpdk.org>
>> Cc: Marchand, David <david.marchand at redhat.com>; Luca Boccassi
>> <bluca at debian.org>
>> Subject: Re: please help backporting some patches to stable release 21.11.9
>>
>> On 28/11/2024 12:48, Richardson, Bruce wrote:
>>> For commit b34fe66ea893 ("net/iavf: delay VF reset command"), I will do a
>> backport for 21.11.
>>>
>>> This will actually be a combination of two commits:
>>> 	0f9ec0cbd2a9 ("net/iavf: fix VF reset when using DCF")
>>> 	b34fe66ea893 ("net/iavf: delay VF reset command")
>>>
>>> Since the referenced commit below is actually a fix for the earlier fix - which
>> was never actually backported to 21.11. Patch will arrive shortly, just build-
>> testing it.
>>>
>>
>> Thanks Bruce. Yep, it wasn't backported as it was causing a build error.
>> My notes say:
>>
>> ../drivers/net/iavf/iavf_ethdev.c: In function ‘iavf_dev_reset’:
>> ../drivers/net/iavf/iavf_ethdev.c:2784:16: error: ‘struct iavf_info’ has
>> no member named ‘in_reset_recovery’
>>  2784 |         if (!vf->in_reset_recovery) {
>>       |                ^~
>>
>> In 23.11.2 LTS the initial fix caused an issue with reset which blocked
>> some validation of iavf, so it was considered a release blocking issue.
>> Your delay VF reset fix, fixed the issue.
>>
>> I'm inclined to be extra cautious about a new patch because it is
>> involving reset of device, previous fix had issue so perhaps there is
>> lack of test coverage (especially for 21.11) and there is no planned
>> opportunity to fix in a later 21.11 LTS.
>>
>> But, if you are confident about it and think the fix is a must have, I
>> can apply.
>>
>> What do you think ?
>>
> I think it should be safe enough to take, and it's not really a new patch as-such.
> 
> The reason the original version of my patch from mainline didn't apply was that it essentially rolled back the original fix and applied a different one. The rollback part is the bit that failed, since the first fix wasn't applied. My "new" patch is therefore the fix that was applied to mainline, just without the lines deleted for rollback.
> 

ok, thanks. I will add a small note to the commit log to note it is
effectively a squash of these commits.

> /Bruce