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 3AC7AA034F; Mon, 29 Mar 2021 10:32:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AC07340151; Mon, 29 Mar 2021 10:32:55 +0200 (CEST) Received: from spider.fraudbuster.mobi (spider.fraudbuster.mobi [62.4.12.223]) by mails.dpdk.org (Postfix) with ESMTP id F213940042 for ; Mon, 29 Mar 2021 10:32:53 +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) server-digest SHA256) (No client certificate requested) by spider.fraudbuster.mobi (Postfix) with ESMTPSA id A52D420375 for ; Mon, 29 Mar 2021 10:32:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fraudbuster.mobi; s=rsa-20200712; t=1617006773; bh=MeHCP91ddZjjGBnwsFPyhIMIxmmqV5Jyd0quiN1JIg8=; h=Subject:From:To:References:Date:In-Reply-To:From; b=LO06zGnIbTuuAS73JsDkEq9msfk3XdKoYj1QSWoZiYB9xwu/7scj1X09wxwmS+dYv LSAhobf52vR9mZZb3eNRTEPKME4zp2ZwBT0twLGRCdZeFI1wVsvB9dDq75XhNN063M uyp9NXOyNq0P9IqtfuuzBhaVZu/dzWiwDBB8d4i0luEBjiI0TrTCLA8KZ3BAnHb86m 2f6eVDaxvvxSSijqZl5AQw5N0VzpAbwtPcjc8zNLDv8pLo44gULXdIi6jXSXuSmOmq iIxnfjcPf/ZV+SaOHrcGqW9C74zmVslybcxvG3eVlnadzQ/8U0eEzyhRlNg2v7YY35 LymNd/QF5G+Zw== From: David Bouyeure To: dev@dpdk.org References: <20210326104217.3397745-2-junfeng.guo@intel.com> <20210326142948.1889704-1-junfeng.guo@intel.com> <20210326142948.1889704-2-junfeng.guo@intel.com> <432d3efe-8f07-971c-ae2a-0fab1b2f07ad@fraudbuster.mobi> Message-ID: <636159f0-3f7e-17d8-7eab-63f9fc6742c2@fraudbuster.mobi> Date: Mon, 29 Mar 2021 10:32:52 +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: <432d3efe-8f07-971c-ae2a-0fab1b2f07ad@fraudbuster.mobi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: A52D420375 X-Rspamd-Server: spider 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] 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" Sorry for the below topic confusion(in-reply-to). On 3/29/21 9:50 AM, David Bouyeure wrote: > Hi, > > > I've found out the pretty useful experimental brand new flow ageing > API implemented in the mlx5 PMD. > > 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. > > 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(). 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) > > 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. > > 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. >