From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 6C063A034F;
	Mon, 29 Mar 2021 10:35:01 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 138A940151;
	Mon, 29 Mar 2021 10:35:01 +0200 (CEST)
Received: from spider.fraudbuster.mobi (spider.fraudbuster.mobi [62.4.12.223])
 by mails.dpdk.org (Postfix) with ESMTP id 3FBAB40042
 for <dev@dpdk.org>; Mon, 29 Mar 2021 10:34:59 +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 0845420375
 for <dev@dpdk.org>; Mon, 29 Mar 2021 10:34:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fraudbuster.mobi;
 s=rsa-20200712; t=1617006899;
 bh=I1BbudeRSyNjOxOXr9eRW/Ked+RVUn1T+6v3rvY2iPI=;
 h=To:From:Subject:Date:From;
 b=QDMumxowFyeWZ/I+40c76QIMasEMm+iGL9gk2lAb9Z3KuVuq5BvY28l+mRWsZHgmh
 cqw5xltVPg61S7j7kARlCAsrZFb6oVuTyPNeRzspuZThkakRlk24lvJr3wQV1Z3hmu
 rY5i88VNOf9vQAiOj0AKph8pjL51eV9fipEy21wNMM4PIPcFhL9cNwVpAXlKOSD5mo
 zjpAoaBadVjDUirA33NLDOUNVGgg5dlOuwg+nf5eIyEElZ4jYMkh5Fm9ezWPIgsCPb
 e+RKL5AfdzwyUNZx74akknkio2dwC6zYq8f15nG9JrdgUuQuTwAX/4e/8wUKndFNpT
 cxaxzL0CUNGDQ==
To: dev@dpdk.org
From: David Bouyeure <david.bouyeure@fraudbuster.mobi>
Message-ID: <26698242-bb7b-baa0-9e61-235ac3725cd7@fraudbuster.mobi>
Date: Mon, 29 Mar 2021 10:34:58 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.3.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Rspamd-Queue-Id: 0845420375
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: [dpdk-dev] rte_flow ageing
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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.