From: David Bouyeure <david.bouyeure@fraudbuster.mobi>
To: Asaf Penso <asafp@nvidia.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: Matan Azrad <matan@nvidia.com>, Jack Min <jackmin@nvidia.com>
Subject: Re: [dpdk-dev] rte_flow ageing
Date: Tue, 30 Mar 2021 17:45:46 +0200 [thread overview]
Message-ID: <1ad78db6-38bd-2e01-0d81-60dd3b256c2a@fraudbuster.mobi> (raw)
In-Reply-To: <DM5PR12MB2406AE08BE84FCD8F92F22F9CD7E9@DM5PR12MB2406.namprd12.prod.outlook.com>
Thanks a lot Asaf, for your answer, so fast.
depending on the feature we want, the table you mentioned in the doc may
give different combinations. Mine, DPDK-20.08/OFED 5.1-2, is part of the
list.
Anyway, my question is more about the API design. Please, find my
comments below.
On 3/29/21 8:02 PM, Asaf Penso wrote:
> 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@dpdk.org> On Behalf Of David Bouyeure
>> Sent: Monday, March 29, 2021 11:35 AM
>> To: dev@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.
I fully understand that and this is a very very useful feature to us.
>> 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.
Sorry, I wasn't realizing that the callback isn't called for each flow
but rather for each port, though it's clear in the PMD code. But, the
fact that we can register several RTE_ETH_EVENT_FLOW_AGED event handlers
is surprising.
So, you suggest to use the callback as an indicator to later retrieve
the aged-out flows, that's it?
Wouldn't calling rte_flow_get_aged_flows with NULL param just to get the
number of aged_flows do the same, without the need to un/register a
callback, and DPDK to call it?
Another thing, the explanation here
http://doc.dpdk.org/api/rte__flow_8h.html#a43763e0794d2696b18b6272619aafc2a
*"...to get the aged flows usynchronously from the event callback..."*
seems wrong to me because age_info->flags is set to 0 just after the
callback, thus ML5_AGE_TRIGGER is canceled and no event will be
triggered before we'll call rte_flow_get_aged_flows() outside of the
callback.
>> 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.
Please forgot :-)
>
>> 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.
next prev parent reply other threads:[~2021-03-30 15:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-29 8:34 David Bouyeure
2021-03-29 18:02 ` Asaf Penso
2021-03-30 15:45 ` David Bouyeure [this message]
2021-04-05 10:23 ` Matan Azrad
2021-04-07 16:19 ` David Bouyeure
2021-04-07 18:09 ` Matan Azrad
2021-04-08 7:50 ` David Bouyeure
2021-04-08 9:52 ` Matan Azrad
2021-04-08 16:45 ` David Bouyeure
-- strict thread matches above, loose matches on Subject: below --
2021-03-26 10:42 [dpdk-dev] [PATCH v2 1/3] net/iavf: support GTPU inner IPv4 for FDIR Junfeng Guo
2021-03-26 14:29 ` [dpdk-dev] [PATCH v3 0/3] support GTPU inner IPv4/IPv6 for AVF FDIR Junfeng Guo
2021-03-26 14:29 ` [dpdk-dev] [PATCH v3 1/3] net/iavf: support GTPU inner IPv4 for FDIR Junfeng Guo
2021-03-29 7:50 ` [dpdk-dev] rte_flow ageing David Bouyeure
2021-03-29 8:32 ` David Bouyeure
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1ad78db6-38bd-2e01-0d81-60dd3b256c2a@fraudbuster.mobi \
--to=david.bouyeure@fraudbuster.mobi \
--cc=asafp@nvidia.com \
--cc=dev@dpdk.org \
--cc=jackmin@nvidia.com \
--cc=matan@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).