[dpdk-dev] rte_flow ageing

Asaf Penso asafp at nvidia.com
Mon Mar 29 20:02:50 CEST 2021


Hello David,

Thanks for reaching out, I'll try to answer as best as I know and I added Matan who will be able to provide further info during next week.
First, according to our pmd documentation (http://doc.dpdk.org/guides/nics/mlx5.html#supported-hardware-offloads) we recommend using DPDK20.11 and OFED5.2, and not the combo you are referring to.
Second, we can always improve our documentation and I appreciate your queries. 

Please see my comments inline.

Regards,
Asaf Penso

>-----Original Message-----
>From: dev <dev-bounces at dpdk.org> On Behalf Of David Bouyeure
>Sent: Monday, March 29, 2021 11:35 AM
>To: dev at dpdk.org
>Subject: [dpdk-dev] rte_flow ageing
>
>Hi,
>
>
>I've found out the pretty useful experimental brand new flow ageing API
>implemented in the mlx5 PMD.

It is useful and I hope you'll fully understand at the end why 😊
 

>
>I'm trying it (rte_eth_dev_callback_register(RTE_ETH_EVENT_FLOW_AGED),
>RTE_FLOW_ACTION_TYPE_AGE) to recover any flow that I previously
>offloaded.
>
>The DPDK version is 20.08 and Mellanox(Connect-X6) OFED drivers are 5.1-
>2.5.8.0.
>

See above the suggested versions for this feature

>I eventually don't see the usefulness of the callback since it's actually triggered
>indirectly by us(the DPDK application) when calling
>rte_flow_get_aged_flows().

The main intention is to offload the aging logic from the application level to the pmd level.
There is so saving of cpu cycles, and the gain here is with simplicity. 
The application doesn't need to have complex logic of comparison between counters or other HW info that can be retrieve.
Now, the pmd hides all of that and leaves the application only to decide what to do with the flows that are aged out.
Please note, the pmd does not delete any flow, just provide the list of all the flows that are aged.

> If we don't call it, the callback is called only once.
>
>And, calling rte_flow_get_aged_flows() from the callback won't trigger it next
>time(MLX5_AGE_TRIGGER is reset after the callback call)

Once you call the function the pmd will not trigger more events. Now it's up to the application to decide what to do.
Doing it differently, will cause an interrupt storm and the pmd avoids that.
If new flows are aged then the pmd will trigger a new event.

>
>Furthermore, I don't see the point of computing ageing flows in
>mlx5_fow.c::mlx5_flow_aging_check() if the client callback isn't called.
>

Can you elaborate? I'm not sure I understand your intention.

>So far, I can handle the flow ageing from the same thread as the one which is
>handling the flow direction(rte_flow), it even avoid threads synchronization.
>But, in the future, I may need to be noticed as soon as possible of a single flow
>ageing, and thus handle this flow logic from the ageing callback.
>
>
>I may misunderstand the whole ageing API... Thanks a lot for any clarification.



More information about the dev mailing list