Re: [PATCH 1/2] common/sfc_efx/base: add API to drop MAE action resource IDs

[Ferruh Yigit <ferruh.yigit@amd.com>]

On 5/18/2023 6:21 PM, Ivan Malov wrote:
> Hi Ferruh,
> 
> Thanks for reviewing this. PSB.
> 
> On Thu, 18 May 2023, Ferruh Yigit wrote:
> 
>> On 4/24/2023 3:30 PM, Ivan Malov wrote:
>>> When the client driver (the DPDK one, for instance) parses user flow
>>> actions, it ends up with an action set specification. Next, in case
>>> there are any FW resource-backed actions, like COUNT or SET_DST_MAC,
>>> the driver allocates these resources and indicates their IDs in the
>>> action set specification. The API used to set these IDs checks that
>>> the current value of the target ID is INVALID, prior to the call.
>>>
>>> The latter check, however, prevents the driver from updating the
>>> IDs on port restart. When the port goes down, the driver frees
>>> the resources. When the port goes up, the driver reallocates
>>> them, tries to set the IDs in the specification and fails.
>>>
>>> In order to address the problem, add an API to drop the
>>> current resource IDs in the actions set specification.
>>>
>>> Fixes: 3907defa5bf0 ("common/sfc_efx/base: support adding encap
>>> action to a set")
>>> Cc: stable@dpdk.org>
>>
>> Hi Ivan,
>>
>> As far as I understand this patch extracts some code into a function, so
>> I expect no functional change in this patch. So not clear what this
>> patch is fixing?
>>
>> And I can see this new API is used in next patch and it fixes an issue.
>> But while backporting this fix to LTS we want both patch to backport
>> because there is a dependency.
>>
>> If there is no functional change in this patch, what about merging these
>> two patches, and explain what is fixed? This also helps backporting.
>>
> 
> As far as I know, changes to different trees (common/sfc_efx/base on the
> one hand and drivers/net/sfc on the other) belong in separate patches.
> Please correct me in case I've got that wrong.
> 
> Anyway, if it's not that hard to backport the two patches in their
> current state, I vote for keeping them like that. I don't insist.
> 

I think changes are simple and can go into single patch to help
dependency between two.