From patchwork Wed Sep 16 11:18:51 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gregory Etelson X-Patchwork-Id: 77895 X-Patchwork-Delegate: thomas@monjalon.net Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id D865FA04C7; Wed, 16 Sep 2020 13:19:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EC59C1C297; Wed, 16 Sep 2020 13:19:29 +0200 (CEST) Received: from hqnvemgate25.nvidia.com (hqnvemgate25.nvidia.com [216.228.121.64]) by dpdk.org (Postfix) with ESMTP id 9CBDD1C297 for ; Wed, 16 Sep 2020 13:19:28 +0200 (CEST) Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate25.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Wed, 16 Sep 2020 04:18:39 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Wed, 16 Sep 2020 04:19:27 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Wed, 16 Sep 2020 04:19:27 -0700 Received: from DRHQMAIL107.nvidia.com (10.27.9.16) by HQMAIL109.nvidia.com (172.20.187.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 16 Sep 2020 11:19:27 +0000 Received: from nvidia.com (172.20.13.39) by DRHQMAIL107.nvidia.com (10.27.9.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 16 Sep 2020 11:19:11 +0000 From: Gregory Etelson To: CC: , , , Ori Kam , Ori Kam , John McNamara , Marko Kovacevic Date: Wed, 16 Sep 2020 14:18:51 +0300 Message-ID: <20200916111854.1949-1-getelson@nvidia.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-Originating-IP: [172.20.13.39] X-ClientProxiedBy: HQMAIL107.nvidia.com (172.20.187.13) To DRHQMAIL107.nvidia.com (10.27.9.16) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1600255120; bh=vAl7P1XJ3V9+fps1F+cgg7yqoL2uXIy3RZeH/qOvyLQ=; h=X-PGP-Universal:From:To:CC:Subject:Date:Message-ID:X-Mailer: MIME-Version:Content-Transfer-Encoding:Content-Type: X-Originating-IP:X-ClientProxiedBy; b=btEvaeiyj11pAHgKOi57cJzBUSwe45GEXchkgU4oaTrfdjICuLcZUtYtLjWaEWi7G umHVkAhGTVytCiT6yw2HUaFs6uBDMYroxPVon+58yEccdnAVfTxXRZ+X0iE12P+y9C +qwQm4WWkvGMvl4rnNEXllDR17clVo2Os9CqLTMop2MkbX0zSAu9/rNVBLPjB5nUGw aduXNkOWi0ejAQsrsJCeo8TRimkZpgrw+RJJamR5jntgVUS3LTltomsnTG0FalW/FU cSC0SWoq14PbCvMH+RThVEqepcComu8MnPeYZJo9yxMpMrrAdZzRdN7YG5owOtpwDg 3Rj87hq8bXoLg== Subject: [dpdk-dev] [PATCH] 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" 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 --- doc/guides/prog_guide/rte_flow.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst index 944e8242d6..dfe5a40f8e 100644 --- a/doc/guides/prog_guide/rte_flow.rst +++ b/doc/guides/prog_guide/rte_flow.rst @@ -3055,10 +3055,9 @@ Caveats temporarily replacing the burst function pointers), an appropriate error code must be returned (``EBUSY``). -- PMDs, not applications, are responsible for maintaining flow rules +- Applications, not PMDs, 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. + actions which may affect them. For devices exposing multiple ports sharing global settings affected by flow rules: