DPDK patches and discussions
 help / color / mirror / Atom feed
From: David Bouyeure <david.bouyeure@fraudbuster.mobi>
To: Matan Azrad <matan@nvidia.com>, Asaf Penso <asafp@nvidia.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: Jack Min <jackmin@nvidia.com>
Subject: Re: [dpdk-dev] rte_flow ageing
Date: Wed, 7 Apr 2021 18:19:34 +0200
Message-ID: <72f4c179-35d3-9139-ccf0-57cceb6a19c2@fraudbuster.mobi> (raw)
In-Reply-To: <MW2PR12MB249242F2B63C7709E62D4E5DDF779@MW2PR12MB2492.namprd12.prod.outlook.com>

Hi Matan, and thanks a lot,

regarding the mode *1*, I still have a doubt:
>
>  1. Register the AGE event -> in event time to query the aged-out
>     flows by the rte_flow_get_aged_flows API, this call will trigger a
>     new event when new aged-out flow will be detected for the port.(if
>     you don’t call rte_flow_get_aged_flows the event will not be
>     retriggered.)
>
You meant calling rte_flow_get_aged_flows() from the event callback I 
guess...?

I think this is not working because MLX5_AGE_TRIGGER is erased when the 
callback returns.


Anyway, the polling mode is enough to me so far.

Thanks again.


Regards.


On 4/5/21 12:23 PM, Matan Azrad wrote:
>
> Hi
>
> I will try to answer inline with prefix [MA].
>
> *From:* David Bouyeure <david.bouyeure@fraudbuster.mobi>
> *Sent:* Tuesday, March 30, 2021 6:46 PM
> *To:* Asaf Penso <asafp@nvidia.com>; dev@dpdk.org
> *Cc:* Matan Azrad <matan@nvidia.com>; Jack Min <jackmin@nvidia.com>
> *Subject:* Re: [dpdk-dev] rte_flow ageing
>
> *External email: Use caution opening links or attachments*
>
> 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  <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdoc.dpdk.org%2Fguides%2Fnics%2Fmlx5.html%23supported-hardware-offloads&data=04%7C01%7Cmatan%40nvidia.com%7Cdfc24177f1fa4209c81f08d8f392e4c2%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637527159538915512%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8xI9xcx8uhHTBDr22aZi986oXyTHTN8E6NKsx%2BYMqAQ%3D&reserved=0>) 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>  <mailto:dev-bounces@dpdk.org>  On Behalf Of David Bouyeure
>
>         Sent: Monday, March 29, 2021 11:35 AM
>
>         To:dev@dpdk.org  <mailto: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.
>
> [MA] Yes you can register the event for each port support aging if you 
> want your callback will be called for “new” aged flows.
>
> So, you suggest to use the callback as an indicator to later retrieve 
> the aged-out flows, that's it?
>
> [MA] the user has 2 options:
>
>  1. Register the AGE event -> in event time to query the aged-out
>     flows by the rte_flow_get_aged_flows API, this call will trigger a
>     new event when new aged-out flow will be detected for the port.(if
>     you don’t call rte_flow_get_aged_flows the event will not be
>     retriggered.)
>  2. Just call rte_flow_get_aged_flows from time to time(application
>     polling).
>
> 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?
>
> [MA]
>
> Here, application need to do polling all the time (option 2), in 
> option 1 application invest effort only when aged-out flows are detected.
>
> In option 1, you can call it with NULL also in order to know what is 
> the array size you need for the actual call.
>
> Another thing, the explanation here 
> http://doc.dpdk.org/api/rte__flow_8h.html#a43763e0794d2696b18b6272619aafc2a 
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdoc.dpdk.org%2Fapi%2Frte__flow_8h.html%23a43763e0794d2696b18b6272619aafc2a&data=04%7C01%7Cmatan%40nvidia.com%7Cdfc24177f1fa4209c81f08d8f392e4c2%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637527159538925502%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=h0Vp1jtf9NKmgywkL4LLOuSDxLR4VzqPH6mS6aD0%2FyI%3D&reserved=0> 
> *"...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.
>
> [MA] It just say you can choose one of the options *usynchronously 
> (option 1), synchronously (option 2).*
>
> Matan
>
>         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.
>

  reply	other threads:[~2021-04-07 16:19 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
2021-04-05 10:23     ` Matan Azrad
2021-04-07 16:19       ` David Bouyeure [this message]
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=72f4c179-35d3-9139-ccf0-57cceb6a19c2@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

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git