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 38B3BA034F; Mon, 29 Mar 2021 09:50:46 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B4CFC40151; Mon, 29 Mar 2021 09:50:45 +0200 (CEST) Received: from spider.fraudbuster.mobi (spider.fraudbuster.mobi [62.4.12.223]) by mails.dpdk.org (Postfix) with ESMTP id B926C40042 for ; Mon, 29 Mar 2021 09:50:44 +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 6D84D21B7A for ; Mon, 29 Mar 2021 09:50:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fraudbuster.mobi; s=rsa-20200712; t=1617004244; bh=I1BbudeRSyNjOxOXr9eRW/Ked+RVUn1T+6v3rvY2iPI=; h=From:Subject:To:References:Date:In-Reply-To:From; b=VQOs+p13DRIgaLoxGm00Dt+7OTM9t92EhGSzzikBoWn4IuSoKpmnAvhiB4Oq9nTSl f+IaDODUsekfIVQNQVVVvx6dAwYCExmJynBe4hJYRcBqo74QgbqRmqp+I/Qf5yB4fk mG2UAmAAy0oG4HRrCN+ptdbZOTBCI3gMibN9Z8qsfN1Ai63uWAVah/LshwA+z/MFHE cjxnKc8LuLeHrl1dqFs8OHtFDg1oRJqiIky9BpiLPohtVNVOK1NWGFYgIPknofHXOd IbWRmO9H4b/7yYacymkRg6aLnqIuuTy5FXTaWtHrlDxZQphq8ABa+1MFNWFnv98Ieu u4LIMktMa/+wQ== 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> Message-ID: <432d3efe-8f07-971c-ae2a-0fab1b2f07ad@fraudbuster.mobi> Date: Mon, 29 Mar 2021 09:50:43 +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: <20210326142948.1889704-2-junfeng.guo@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: 6D84D21B7A X-Rspamd-Server: spider Subject: [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, 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.