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 3DC90A04B1; Tue, 24 Nov 2020 15:41:29 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A7313C924; Tue, 24 Nov 2020 15:41:27 +0100 (CET) Received: from mail-oi1-f196.google.com (mail-oi1-f196.google.com [209.85.167.196]) by dpdk.org (Postfix) with ESMTP id 63814C914 for ; Tue, 24 Nov 2020 15:41:25 +0100 (CET) Received: by mail-oi1-f196.google.com with SMTP id d9so24025853oib.3 for ; Tue, 24 Nov 2020 06:41:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D9P3mPqu4SOlQSHoRX9hTbS3/WwjONBcm+6dB4ddJ1M=; b=FNJmXo900BoCGjPSzf3wx2h+wdS8Lp8teqmnufsCC/SO9nmAQIaV8raHU1n/EBNzfH uoSav5enAeZvUwpYWRF5oKYJsrChbW3ui1BGwe+e5XznU2mbXnQ+1sQjz30fLlbVRBqJ cv9sQsD+WKt7pNlIYUuw2WlMqCHrhOMHnxHyk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D9P3mPqu4SOlQSHoRX9hTbS3/WwjONBcm+6dB4ddJ1M=; b=XkoidaLBnBXklLD5CPhwXiHTlyhgKuJKh5ErengY2cqeOupf9pQOctp/C29DxP/JMA 66tJKKfDaLjhD/6b4KmsZWW66zOK8XvTMfOGbF4leWo8+LqYjSqWYM4iwlOdsI4qmXpG QPhrmSvBgd3mx1LVvrhyvm2HJ06EDaKSVOzMtFZ3KkUvk/qxE2h/a29eAWQbI4+Po7Oe 03vitcuo2uXTI+fNpqY6VXi0i5KBeYDPcSolsldKj0jpy8nWH97kbaUH+QshyZ7nfmfF OyTx3T5tSo6+r9wR3Zz14/gIcWip0S64BkSphpgetRM5caxkiHhNSA72NVtBq9R9ah2P BD+A== X-Gm-Message-State: AOAM531yHfplpaFYJPK04v2asEDaSo3fnC02soSZRK+Gzv9gMG/p9GgU oUHhl78NkndPUTMk/wiUXqzLnrilaNtV7H7W3DgcRQ== X-Google-Smtp-Source: ABdhPJzH9frEYwyqfvMmF+zqRZKNzOHjNAu6kG5ActJK0NkeXS/LJD764O+CN0LuX6ljuNeWNP74DrEZA5Heo3tysLQ= X-Received: by 2002:aca:53cc:: with SMTP id h195mr2920977oib.168.1606228883479; Tue, 24 Nov 2020 06:41:23 -0800 (PST) MIME-Version: 1.0 References: <20200916111854.1949-1-getelson@nvidia.com> <20201118161520.4378-1-getelson@nvidia.com> In-Reply-To: <20201118161520.4378-1-getelson@nvidia.com> From: Ajit Khaparde Date: Tue, 24 Nov 2020 06:41:07 -0800 Message-ID: To: Gregory Etelson Cc: dpdk-dev , Matan Azrad , Thomas Monjalon , Andrew Rybchenko , Ori Kam Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v2] doc: flow rule removal on port stop 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 Wed, Nov 18, 2020 at 8:15 AM Gregory Etelson wrote: > > There is a discrepancy between RTE ETHDEV API and flow rules guide > regarding flow rules maintenance after port stop. RTE ETHDEV API in > librte_ethdev.h declares that flow rules will not be stored in PMD > after port stop: > >>>>> Quite start > Please note that some configuration is not stored between calls to > rte_eth_dev_stop()/rte_eth_dev_start(). The following configuration > will be retained: > > - MTU > - flow control settings > - receive mode configuration (promiscuous mode, all-multicast mode, > hardware checksum mode, RSS/VMDQ settings etc.) > - VLAN filtering configuration > - default MAC address > - MAC addresses supplied to MAC address array > - flow director filtering mode (but not filtering rules) > - NIC queue statistics mappings > <<<< Quote end > > PMD cannot always correctly restore flow rules after port stop / port > start because application may alter port configuration after port stop > without PMD knowledge about undergoing changes. Consider the > following scenario: > application configures 2 queues 0 and 1 and creates a flow rule with > 'queue index 1' action. After that application stops the port and > removes queue 1. > Although PMD can implement flow rule shadow copy to be used for > restore after port start, attempt to restore flow rule from shadow > will fail in example above and PMD could not notify application about > that failure. As the result, flow rules map in HW will differ from > what application expects. In addition, flow rules shadow copy used > for port start restore consumes considerable amount of system memory, > especially in systems with millions of flow rules. > > Signed-off-by: Gregory Etelson > Acked-by: Ori Kam Acked-by: Ajit Khaparde > --- > doc/guides/prog_guide/rte_flow.rst | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst > index ea203e0ca4..4cff9332fa 100644 > --- a/doc/guides/prog_guide/rte_flow.rst > +++ b/doc/guides/prog_guide/rte_flow.rst > @@ -3229,10 +3229,12 @@ Caveats > temporarily replacing the burst function pointers), an appropriate error > code must be returned (``EBUSY``). > > -- PMDs, not applications, are responsible for maintaining flow rules > - configuration when stopping and restarting a port or performing other > - actions which may affect them. They can only be destroyed explicitly by > - applications. > +- Applications, not PMDs, are responsible for maintaining flow rules > + configuration when closing, stopping or restarting a port or performing other > + actions which may affect them. > + Applications must assume that after port close, stop or restart all flows > + related to that port are not valid, hardware rules are destroyed and relevant > + PMD resources are released. > > For devices exposing multiple ports sharing global settings affected by flow > rules: > -- > 2.29.2 >