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

[Ivan Malov]

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 at 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.

Thank you.