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

[Ferruh Yigit]

On 5/19/2023 10:01 AM, Ivan Malov wrote:
> Hi Ferruh,
> 
> On Fri, 19 May 2023, Ferruh Yigit wrote:
> 
>> 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 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.
>>>
>>
>> I think changes are simple and can go into single patch to help
>> dependency between two.
>>
>>
> Thanks for perseverance. Now you mention it, what prefix in the summary
> should I use? Just "drivers: "? For the unified patch, that is.
> 

updated as 'net/sfc: ...' while merging.