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 89F57A0559; Mon, 16 Mar 2020 17:13:38 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E07CD1C0AB; Mon, 16 Mar 2020 17:13:37 +0100 (CET) Received: from mail-pj1-f67.google.com (mail-pj1-f67.google.com [209.85.216.67]) by dpdk.org (Postfix) with ESMTP id CE84C1C045 for ; Mon, 16 Mar 2020 17:13:36 +0100 (CET) Received: by mail-pj1-f67.google.com with SMTP id nu11so5718545pjb.1 for ; Mon, 16 Mar 2020 09:13:36 -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=lIFGCae4BOtBvbQrusYScZAiXZjA8fpCdRLx6WqPC5M=; b=i5s4oPc6ic266B1Z2TJaw+9E37/32uN4IpccBnip3sMkW/YcUJ8e5a0HinFPLEFnS1 2Gx72I0WPCo/Il/sqe6emp0axuEvoyIwBFj7xJSyxJswHnoUjWaKV68t18bjLqwCtulU SNVrSnvDfSJ1++ECzKqy5j1frjHpnwdey94tEnc31tFpBS419SC3ETu6ObejW01KeCYF Gw3GlVjG5q9JztzGc8ZWGnfJoGK8WFN2KtG7EhJDA4UVMeVIxcN83N7SNBmBFhaHIkbX 5/wLDSRB3ZD5Nk41oijnIsgZkxTr8qFgZ2fo03DBrOUOogqvluY8VuxxrxFj69WhHzYC QRCQ== 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=lIFGCae4BOtBvbQrusYScZAiXZjA8fpCdRLx6WqPC5M=; b=HG1Bb8auoMdl+F5aNsjEl00rjF7oLZBk1elnOOwDkHuAiyCFwryTvk2iupYlA4nBW8 M+uiY6OvvoqN0cAO6jWKwDXvX8TwAzZr25Vj8/H0JcxsaGa7QxilunPMskojYoNx4fj0 CiwbIxPRsQaNfguiFQxi0pDxhLHwq8H+AkQpNGrCeZBcD9qqw5FM9Q6Mb3DS+Upd8WTV PY8LEyR79deZEvNGbnmuacxUv8ipq+CW1qONUOvIbZC5RlbDJyMDgbvGoDzCjKI4I8UI g+xaCqshA6htkrvQpGPRISqP5a8GCu4VlN33YVog0CXK+/qBkI2scen1LKjCKA/iZXMZ 868A== X-Gm-Message-State: ANhLgQ0IxU8tHSVaGOstF+uq/SnZgW8pQ64ERrXSjf9Tvk0zCNkl7WHq c5frUwjgDFJeVpBlGQ+YpVmfKQ== X-Google-Smtp-Source: ADFU+vtMLK2I0vmyGnaQfJulRbAyXppc5dLRbA6ELUbni9A2xw744u/MNK1i+iL/qdCEMWH9r99nIQ== X-Received: by 2002:a17:902:bf07:: with SMTP id bi7mr25845284plb.164.1584375216058; Mon, 16 Mar 2020 09:13:36 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id u126sm333284pfu.182.2020.03.16.09.13.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Mar 2020 09:13:35 -0700 (PDT) Date: Mon, 16 Mar 2020 09:13:27 -0700 From: Stephen Hemminger To: Jerin Jacob Kollanukkaran Cc: Matan Azrad , Adrien Mazarguil , "dev@dpdk.org" Message-ID: <20200316091327.2c66ae48@hermes.lan> In-Reply-To: References: <1558865893-23381-1-git-send-email-matan@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] [RFC] 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 Thu, 6 Jun 2019 12:15:50 +0000 Jerin Jacob Kollanukkaran wrote: > > -----Original Message----- > > From: Matan Azrad > > Sent: Thursday, June 6, 2019 4:22 PM > > To: Jerin Jacob Kollanukkaran ; Adrien Mazarguil > > ; dev@dpdk.org > > Subject: [EXT] RE: [PATCH] [RFC] ethdev: support flow aging > > > > Hi Jerin > > Hi Matan, > > > > > From: Jerin Jacob > > > > -----Original Message----- > > > > From: dev On Behalf Of Matan Azrad > > > > Sent: Sunday, May 26, 2019 3:48 PM > > > > To: Adrien Mazarguil ; dev@dpdk.org > > > > Subject: [dpdk-dev] [PATCH] [RFC] ethdev: support flow aging > > > > > > > > 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 no any dpdk mechanism for flow aging and the > > > > applications use there own ways to detect and destroy aged-out flows. > > > > > > > > This RFC introduces flow aging APIs to offload the flow aging task > > > > from the application to the port. > > > > > > > > Design: > > > > - 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. > > > > > > > > By this design each PMD can use its best way to do the aging with > > > > the device offloads supported by its HW. > > > > > > > > Signed-off-by: Matan Azrad > > > > --- > > > > lib/librte_ethdev/rte_ethdev.h | 1 + > > > > lib/librte_ethdev/rte_flow.h | 56 > > > > ++++++++++++++++++++++++++++++++++++++++++ > > > > 2 files changed, 57 insertions(+) > > > > > > > > diff --git a/lib/librte_ethdev/rte_ethdev.h > > > > b/lib/librte_ethdev/rte_ethdev.h index 1f35e1d..6fc1531 100644 > > > > --- a/lib/librte_ethdev/rte_ethdev.h > > > > +++ b/lib/librte_ethdev/rte_ethdev.h > > > > @@ -2771,6 +2771,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 detected in > > > > the port > > > Does this event supported in HW? > > It depends in the PMD implementation and HW capability. > > > > > Or Are planning to implement with alarm or timer. > > Again, depends in the PMD implementation. > > > > > Just asking because, if none of the HW supports the interrupt then > > > only rte_flow_get_aged_flows sync API be enough() > > Why? > > If none of the HW supports it then application/common code can periodically polls it. > If mlx5 hw supports it then it fine to have interrupt. > But I think, we need to have means to express a HW/Implementation does not support its > As there may following reasons why drivers choose to not take timer/alarm path > 1) Some EAL port does not support timer/alarm example: FreeBSD DPDK port > 2) If we need to support a few killo rules then timer/alarm implementation will be heavy > So an option to express un supported event would be fine. This API needs to be defined in a way that it is possible to write an application that works on multiple types of hardware. This is often hard to do with DPDK because too often API's are added that are convenient for the driver writer. There must be only one way that flow aging notifications happen, and they must only occur in a specific context. Is this in a normal DPDK thread, or in interrupt thread, or alarm thread. Choose one and make all drivers do the same thing.