[1/2] common/sfc_efx/base: add API to drop MAE action resource IDs
Checks
Commit Message
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
Signed-off-by: Ivan Malov <ivan.malov@arknetworks.am>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
Tested-by: Denis Pryazhennikov <denis.pryazhennikov@arknetworks.am>
---
drivers/common/sfc_efx/base/efx.h | 14 ++++++++++++++
drivers/common/sfc_efx/base/efx_impl.h | 4 ++++
drivers/common/sfc_efx/base/efx_mae.c | 15 +++++++++++----
drivers/common/sfc_efx/version.map | 1 +
4 files changed, 30 insertions(+), 4 deletions(-)
Comments
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.
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.
Thank you.
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.
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
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@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.
@@ -4774,6 +4774,20 @@ efx_mae_action_set_fill_in_counter_id(
__in efx_mae_actions_t *spec,
__in const efx_counter_t *counter_idp);
+/*
+ * Clears dangling FW object IDs (counter ID, for instance) in
+ * the action set specification. Useful for adapter restarts,
+ * when all MAE objects need to be reallocated by the driver.
+ *
+ * This method only clears the IDs in the specification.
+ * The driver is still responsible for keeping the IDs
+ * separately and freeing them when stopping the port.
+ */
+LIBEFX_API
+extern void
+efx_mae_action_set_clear_fw_rsrc_ids(
+ __in efx_mae_actions_t *spec);
+
/* Action set ID */
typedef struct efx_mae_aset_id_s {
uint32_t id;
@@ -1802,6 +1802,10 @@ typedef struct efx_mae_action_vlan_push_s {
uint16_t emavp_tci_be;
} efx_mae_action_vlan_push_t;
+/*
+ * Helper efx_mae_action_set_clear_fw_rsrc_ids() is responsible
+ * to initialise every field in this structure to INVALID value.
+ */
typedef struct efx_mae_actions_rsrc_s {
efx_mae_mac_id_t emar_dst_mac_id;
efx_mae_mac_id_t emar_src_mac_id;
@@ -1394,10 +1394,7 @@ efx_mae_action_set_spec_init(
goto fail1;
}
- spec->ema_rsrc.emar_dst_mac_id.id = EFX_MAE_RSRC_ID_INVALID;
- spec->ema_rsrc.emar_src_mac_id.id = EFX_MAE_RSRC_ID_INVALID;
- spec->ema_rsrc.emar_eh_id.id = EFX_MAE_RSRC_ID_INVALID;
- spec->ema_rsrc.emar_counter_id.id = EFX_MAE_RSRC_ID_INVALID;
+ efx_mae_action_set_clear_fw_rsrc_ids(spec);
/*
* Helpers which populate v2 actions must reject them when v2 is not
@@ -3027,6 +3024,16 @@ efx_mae_action_set_fill_in_counter_id(
return (rc);
}
+ void
+efx_mae_action_set_clear_fw_rsrc_ids(
+ __in efx_mae_actions_t *spec)
+{
+ spec->ema_rsrc.emar_dst_mac_id.id = EFX_MAE_RSRC_ID_INVALID;
+ spec->ema_rsrc.emar_src_mac_id.id = EFX_MAE_RSRC_ID_INVALID;
+ spec->ema_rsrc.emar_eh_id.id = EFX_MAE_RSRC_ID_INVALID;
+ spec->ema_rsrc.emar_counter_id.id = EFX_MAE_RSRC_ID_INVALID;
+}
+
__checkReturn efx_rc_t
efx_mae_counters_alloc(
__in efx_nic_t *enp,
@@ -90,6 +90,7 @@ INTERNAL {
efx_mae_action_rule_insert;
efx_mae_action_rule_remove;
efx_mae_action_set_alloc;
+ efx_mae_action_set_clear_fw_rsrc_ids;
efx_mae_action_set_fill_in_counter_id;
efx_mae_action_set_fill_in_dst_mac_id;
efx_mae_action_set_fill_in_eh_id;