From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 74751A0597; Sat, 18 Apr 2020 00:07:43 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 289861DD65; Sat, 18 Apr 2020 00:07:43 +0200 (CEST) Received: from mail-pg1-f195.google.com (mail-pg1-f195.google.com [209.85.215.195]) by dpdk.org (Postfix) with ESMTP id 828A11D5EB for ; Sat, 18 Apr 2020 00:07:42 +0200 (CEST) Received: by mail-pg1-f195.google.com with SMTP id t11so1754600pgg.2 for ; Fri, 17 Apr 2020 15:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=F9luooiEY/xCYSoVG5T5eBERfnpYj8yJRysb19kkYoI=; b=nh1UYt/W1iFf66vcqI1BmYVYv4RZbU+4eP6UQW/HWcf6r6AMZ4gNO4Is8W0E2GbbNF 2oFRpMMpD9SS/zejt8tWt3+vQH0lm1XJdctJrk0zgEOfyj72WNpGTm+SjnOyJZDnHdTw SW+cEH2WsXno7vJTZAfOO6FXEHRDEdtI35eoesarNjvBfEQmCUim+w2zhmHekOty0Zvh C3JjhOpGQuoRbhG2o9k1JKWZB0dyKqbDRDn68pcK0b0NxSsDoEr52lLXqubRRBNrV+A5 7M73pacX9I4kTOyzkq1y87OwzzxPzJDxakyuSjndQj+Jxll8lOJlp6ON46toK5QgRyL4 xBdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=F9luooiEY/xCYSoVG5T5eBERfnpYj8yJRysb19kkYoI=; b=N6bgvg/7udawy0IJSag0DIMqmkGwMXY6EN05CdzQoMdhPWdBWA6abz/GYGGxaOTLoy 1KhLJGzk9kWU+j4SZrV7tSEv+6U3ZgtOter2erhOV1S4XWoJnRLSv3obPe918L8ec8m9 QTYP0HI93oy5cZwosuSK305R5a5+L3Cumhqu43qenrgOT5htuxOFH4gujOPQVFImfpfH KsDnkOwUXfFwF6bdm8mKHELcWZTNhOmqo6zmP4FLk0I6CnRKd1fRj9bf47kVBe/BS2eY k2qKegs0Pm6+uNxo04ULQ+wzGGz+Waah3j2QGWnx8BYWV5l90sXd/0gpCCXr9uz63wF9 hoRg== X-Gm-Message-State: AGi0PubbW0iWxDPQD712iui5Zm0ELFgkQ/Re7oFK//gzBb2uos9k19qx EpkcEQgxt0SLiBtNEytkuDrLqg== X-Google-Smtp-Source: APiQypK2iCWqYUTmuu8VPWPI/OkvHlGWy5/tFtyEbeA+A1IFZcWMsLDzePLh/ewvzTBxpcpPammRtg== X-Received: by 2002:a62:13:: with SMTP id 19mr1532003pfa.64.1587161261616; Fri, 17 Apr 2020 15:07:41 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id y22sm20651064pfr.68.2020.04.17.15.07.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Apr 2020 15:07:41 -0700 (PDT) Date: Fri, 17 Apr 2020 15:07:32 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: Dong Zhou , orika@mellanox.com, matan@mellanox.com, wenzhuo.lu@intel.com, jingjing.wu@intel.com, bernard.iremonger@intel.com, john.mcnamara@intel.com, marko.kovacevic@intel.com, thomas@monjalon.net, arybchenko@solarflare.com, dev@dpdk.org Message-ID: <20200417150732.4668bbf8@hermes.lan> In-Reply-To: <192e2e54-17fe-5444-1917-3982837f6e5c@intel.com> References: <20200410094631.31330-1-dongz@mellanox.com> <20200414083255.14014-1-dongz@mellanox.com> <192e2e54-17fe-5444-1917-3982837f6e5c@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] ethdev: support flow aging X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" On Fri, 17 Apr 2020 23:00:57 +0100 Ferruh Yigit wrote: > On 4/14/2020 9:32 AM, Dong Zhou wrote: > > One of the reasons to destroy a flow is the fact that no packet matches the > > flow for "timeout" time. > > For example, when TCP\UDP sessions are suddenly closed. > > > > Currently, there is not any DPDK mechanism for flow aging and the > > applications use their own ways to detect and destroy aged-out flows. > > > > The flow aging implementation need include: > > - A new rte_flow action: RTE_FLOW_ACTION_TYPE_AGE to set the timeout and > > the application flow context for each flow. > > - A new ethdev event: RTE_ETH_EVENT_FLOW_AGED for the driver to report > > that there are new aged-out flows. > > - A new rte_flow API: rte_flow_get_aged_flows to get the aged-out flows > > contexts from the port. > > - Support input flow aging command line in Testpmd. > > > > Signed-off-by: Dong Zhou > > <...> > > > --- a/lib/librte_ethdev/rte_ethdev.h > > +++ b/lib/librte_ethdev/rte_ethdev.h > > @@ -3015,6 +3015,7 @@ enum rte_eth_event_type { > > RTE_ETH_EVENT_NEW, /**< port is probed */ > > RTE_ETH_EVENT_DESTROY, /**< port is released */ > > RTE_ETH_EVENT_IPSEC, /**< IPsec offload related event */ > > + RTE_ETH_EVENT_FLOW_AGED,/**< New aged-out flows is detected */ > > RTE_ETH_EVENT_MAX /**< max value of this enum */ > > }; > > > Just recognized that this is failing in ABI check [1], as far as last time for a > similar enum warning a QAT patch has been dropped, should this need to wait for > 20.11 too? > > > [1] > [C]'function int _rte_eth_dev_callback_process(rte_eth_dev*, > rte_eth_event_type, void*)' at rte_ethdev.c:4063:1 has some indirect sub-type > changes: > parameter 2 of type 'enum rte_eth_event_type' has sub-type changes: > type size hasn't changed > 1 enumerator insertion: > 'rte_eth_event_type::RTE_ETH_EVENT_FLOW_AGED' value '10' > 1 enumerator change: > 'rte_eth_event_type::RTE_ETH_EVENT_MAX' from value '10' to '11' at > rte_ethdev.h:3008:1 > For 20.11, those _MAX values need to be removed from enums