From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C0944A0C3F; Wed, 7 Apr 2021 18:19:36 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AB650140F3C; Wed, 7 Apr 2021 18:19:36 +0200 (CEST) Received: from spider.fraudbuster.mobi (spider.fraudbuster.mobi [62.4.12.223]) by mails.dpdk.org (Postfix) with ESMTP id 73E2C140F29 for ; Wed, 7 Apr 2021 18:19:35 +0200 (CEST) Received: from [10.8.0.214] (gypsy.fraudbuster.mobi [212.129.1.221]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by spider.fraudbuster.mobi (Postfix) with ESMTPSA id EB897221BB; Wed, 7 Apr 2021 18:19:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fraudbuster.mobi; s=rsa-20200712; t=1617812375; bh=BnBHHK6fD8bXlA9V+JgYNbdTEv8tTOVX6IDlaFyJOfk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=KQ7PF59Nh+oDW5/fMLBIjPsfGWaQxL1N1KE6PzNmMvSurBF6Sn/Wgu9tQ+hyuhBdE qkzvQjNMawMy3DQpsGR/Pf1ffTpXmxTIbctSl6iinQHCfnWnO2bi7VUBiEXfyKJkVe t+jLopq3og+rxAy3nuF5OoMmWziBUDlOBRgy0ZAf4+CVwSZIZoLQ9Eob4QYr3NlJf2 IxUQyMrbBOE6G03MOOMO1hKJDhwefsJBFUreGM1t4Ql6KQhII/G+gRvOmDTs0gcbUS AZT2z+xgQ/hk08TKvA2oNWXdwdwUOU8Zxm1YjfMxWCrxuOxQZsf3bKpk1Jk6MClNFw dgvbJoeD4PL9w== To: Matan Azrad , Asaf Penso , "dev@dpdk.org" Cc: Jack Min References: <26698242-bb7b-baa0-9e61-235ac3725cd7@fraudbuster.mobi> <1ad78db6-38bd-2e01-0d81-60dd3b256c2a@fraudbuster.mobi> From: David Bouyeure Message-ID: <72f4c179-35d3-9139-ccf0-57cceb6a19c2@fraudbuster.mobi> Date: Wed, 7 Apr 2021 18:19:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:12876, ipnet:212.129.0.0/18, country:FR]; IP_WHITELIST(0.00)[212.129.1.221] X-Rspamd-Queue-Id: EB897221BB X-Rspamd-Server: spider Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-dev] rte_flow ageing X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > *Sent:* Tuesday, March 30, 2021 6:46 PM > *To:* Asaf Penso ; dev@dpdk.org > *Cc:* Matan Azrad ; Jack Min > *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 ) 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 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. > > [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 > > *"...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. >