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

[Ivan Malov <ivan.malov@arknetworks.am>]

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

Ivan