From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id EA93FA0524; Mon, 19 Apr 2021 14:44:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C6D57412D3; Mon, 19 Apr 2021 14:44:58 +0200 (CEST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2056.outbound.protection.outlook.com [40.107.92.56]) by mails.dpdk.org (Postfix) with ESMTP id 25AEB412D1 for ; Mon, 19 Apr 2021 14:44:57 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NUmD6Ye+squvQTD25iFJa6BlOQ8TI0/nvOYAG3Q7raDW/TKrQfVz2eFMqrtOoenA4pAUKitbg0stS9F1wzytv9MTLck8XByvggPJugQDV7FPgiUdcgy3tl7OGLoWvV8gsvcgP/auV/sX1M5cyunhYy7FUkee9iQnjSAoAr9ck7B7ifAuxVYJqGl0G5gzO/ETFNG7ik8B+jbBNmb4D0GH0RvVkAzNCHJ+1Rx0BhYIsGU0vH/tAbGXgIr9mT9vaZIvkFjeY2hknY3cNxvHYpy57yR32H/VR1DbXT2QTxFxuL9p9u6rVBxjsBtgtyN97VorevEKnSZMrTLamcZICWjRHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CZBOVXd5p2AsqAndsyIdXxkXjT5OURZSHWDOY7ihDrc=; b=M6jH3ZqIRzFfyKjhUWwufK+G2wzauPEged7D3YZNsFehi5+0F4/rAJmqO3jGtxVOCFrGUh/LFCSAZHGRve4HK3gYkTLEO5eWD4TKfSVmYVmJC1k6/ZgN/J6idsNokrwtckUxLLkKs1idEpEkXrccjfzPL7Nurl8hAjyaen3daG+tJUGQZQR1+AJ658EJLraqB/ZsrXGYBVdvLv9VH08z7Hby5KZ92lvn8DLQS8Bqe5R4ruU6AucPFcgKgu9P8iFb1rpCIjP6vzmeLRq/E2SLQDuVhwEszV1vYjxNh0LHU8EHuam5vsXaZLqNN3Tf6vCUNuSR8o7sw0taonbOoXkiug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 216.228.112.34) smtp.rcpttodomain=gmail.com smtp.mailfrom=nvidia.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=nvidia.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CZBOVXd5p2AsqAndsyIdXxkXjT5OURZSHWDOY7ihDrc=; b=WoeNYXU1cCk8MhnaAAiQyefUk5J6bv7OOTKadWeR9rm8V51BSaERN0+qEzIGyXw0VPYQMbbmFlY9rX7NywVbIJrS9nt2P/w/+Q/bSVUDzO7duoAmYyspNERVgu1ufYwbrhLb2PPIbGhSuJeK7t5IhKatg0ZbW5yhu6j+RXvfE9vtXT7FPZvRSW/SZE1w/eVyeX0HCVBbkPPecJwp1BGGqR+sycT1OmezBYRMf515P3rJFr18HFLw3qLW8qwEVweUO+F+6t6Wr7HDEQ8Bn1w2Jj7EZqYJzYAK3hbFLlV/kOqX6x7f8MHC/lelJA/zGmdR2hRsKd3p2ThxMrkTN/pc6Q== Received: from BN9PR03CA0127.namprd03.prod.outlook.com (2603:10b6:408:fe::12) by MN2PR12MB3711.namprd12.prod.outlook.com (2603:10b6:208:161::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.24; Mon, 19 Apr 2021 12:44:53 +0000 Received: from BN8NAM11FT059.eop-nam11.prod.protection.outlook.com (2603:10b6:408:fe:cafe::45) by BN9PR03CA0127.outlook.office365.com (2603:10b6:408:fe::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16 via Frontend Transport; Mon, 19 Apr 2021 12:44:53 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 216.228.112.34) smtp.mailfrom=nvidia.com; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=pass action=none header.from=nvidia.com; Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates 216.228.112.34 as permitted sender) receiver=protection.outlook.com; client-ip=216.228.112.34; helo=mail.nvidia.com; Received: from mail.nvidia.com (216.228.112.34) by BN8NAM11FT059.mail.protection.outlook.com (10.13.177.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.4042.16 via Frontend Transport; Mon, 19 Apr 2021 12:44:53 +0000 Received: from nvidia.com (172.20.145.6) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 19 Apr 2021 12:44:49 +0000 From: Gregory Etelson To: CC: , , , , , , , , , , , Date: Mon, 19 Apr 2021 15:44:30 +0300 Message-ID: <20210419124431.21826-2-getelson@nvidia.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210419124431.21826-1-getelson@nvidia.com> References: <20210419124431.21826-1-getelson@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [172.20.145.6] X-ClientProxiedBy: HQMAIL105.nvidia.com (172.20.187.12) To HQMAIL107.nvidia.com (172.20.187.13) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 836e4290-e088-436c-c58f-08d90330edd3 X-MS-TrafficTypeDiagnostic: MN2PR12MB3711: X-LD-Processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr X-Microsoft-Antispam-PRVS: X-MS-Exchange-Transport-Forked: True X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: KSVWhmU7UBxj0UAqVfpH4fveUPmcumI+Lagp3eQ4zPazq4T53TpWpK4BZjBNAaz/Qjiest0VrHx1IHO/pcdrKYWOf2YGeFmOfUMmwgwzG5Mtxe9hWEGRdaw3n6Isl97KUVFrSeitLZEWmP4JFyH06/7wV4gNIK6GnONpwsGdCATv9+XLCqQnRFMtmN3PTy4ZuY+lE2/RNDym/QFMuSpTidEQ72vQF82u9xfl2sjoNxe6Tlx8xbxDw7K/mHbfvJ7qZWGtWyZmuecFe3hvh/am7W7lU7RH+IvUdLVFwYPUtjb3bBZExY7UF5eh4tsasllssgMrfx9R2WZGytEufPjvPlzshsl4d04xANRuaup1LrOAUUASoiYqTJ7Q8TJC1WpzEOZa5dTZBnHe3qBSbswYYEcJwGCRUXlhMJeMiA1/bLWknGFgNeeZowTJh7EwBTAmgVO7EklU+aDzzgxNoy8QBE5IAeCgPZNk4XqD7f/7U3ZSUZc1Za2byIbJFsHmsjCLQOTUlWGg9KU7OqB/mFJjmWIfITqz7dWYw76/K+SeVJ6oNNdThEaK7TMpr0YbgUp+HSTnaylurTukDF7rVq6KC11+d2iOtWzQADmF8YXAs9YkRx+nVPUxeoT03Iatkt3g0eQRuqx/d+BcQPt1bG4xjaKH86Gh0a0eaKOXf2/UCe4= X-Forefront-Antispam-Report: CIP:216.228.112.34; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:mail.nvidia.com; PTR:schybrid03.nvidia.com; CAT:NONE; SFS:(4636009)(346002)(136003)(39860400002)(396003)(376002)(36840700001)(46966006)(6636002)(55016002)(54906003)(37006003)(426003)(6286002)(82740400003)(36906005)(86362001)(2616005)(336012)(316002)(83380400001)(6666004)(26005)(478600001)(16526019)(70206006)(7636003)(7696005)(36756003)(70586007)(5660300002)(2906002)(1076003)(356005)(8936002)(47076005)(8676002)(82310400003)(6862004)(36860700001)(107886003)(186003)(4326008); DIR:OUT; SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Apr 2021 12:44:53.1189 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 836e4290-e088-436c-c58f-08d90330edd3 X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a; Ip=[216.228.112.34]; Helo=[mail.nvidia.com] X-MS-Exchange-CrossTenant-AuthSource: BN8NAM11FT059.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB3711 Subject: [dpdk-dev] [PATCH v8 1/2] ethdev: add packet integrity checks X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" From: Ori Kam Currently, DPDK application can offload the checksum check, and report it in the mbuf. However, as more and more applications are offloading some or all logic and action to the HW, there is a need to check the packet integrity so the right decision can be taken. The application logic can be positive meaning if the packet is valid jump / do actions, or negative if packet is not valid jump to SW / do actions (like drop) and add default flow (match all in low priority) that will direct the miss packet to the miss path. Since currently rte_flow works in positive way the assumption is that the positive way will be the common way in this case also. When thinking what is the best API to implement such feature, we need to consider the following (in no specific order): 1. API breakage. 2. Simplicity. 3. Performance. 4. HW capabilities. 5. rte_flow limitation. 6. Flexibility. First option: Add integrity flags to each of the items. For example add checksum_ok to ipv4 item. Pros: 1. No new rte_flow item. 2. Simple in the way that on each item the app can see what checks are available. Cons: 1. API breakage. 2. increase number of flows, since app can't add global rule and must have dedicated flow for each of the flow combinations, for example matching on icmp traffic or UDP/TCP traffic with IPv4 / IPv6 will result in 5 flows. Second option: dedicated item Pros: 1. No API breakage, and there will be no for some time due to having extra space. (by using bits) 2. Just one flow to support the icmp or UDP/TCP traffic with IPv4 / IPv6. 3. Simplicity application can just look at one place to see all possible checks. 4. Allow future support for more tests. Cons: 1. New item, that holds number of fields from different items. For starter the following bits are suggested: 1. packet_ok - means that all HW checks depending on packet layer have passed. This may mean that in some HW such flow should be splited to number of flows or fail. 2. l2_ok - all check for layer 2 have passed. 3. l3_ok - all check for layer 3 have passed. If packet doesn't have l3 layer this check should fail. 4. l4_ok - all check for layer 4 have passed. If packet doesn't have l4 layer this check should fail. 5. l2_crc_ok - the layer 2 crc is O.K. 6. ipv4_csum_ok - IPv4 checksum is O.K. it is possible that the IPv4 checksum will be O.K. but the l3_ok will be 0. it is not possible that checksum will be 0 and the l3_ok will be 1. 7. l4_csum_ok - layer 4 checksum is O.K. 8. l3_len_OK - check that the reported layer 3 len is smaller than the frame len. Example of usage: 1. check packets from all possible layers for integrity. flow create integrity spec packet_ok = 1 mask packet_ok = 1 ..... 2. Check only packet with layer 4 (UDP / TCP) flow create integrity spec l3_ok = 1, l4_ok = 1 mask l3_ok = 1 l4_ok = 1 Signed-off-by: Ori Kam Acked-by: Ferruh Yigit --- doc/guides/prog_guide/rte_flow.rst | 22 ++++++++++++ doc/guides/rel_notes/release_21_05.rst | 5 +++ lib/librte_ethdev/rte_flow.h | 50 ++++++++++++++++++++++++++ 3 files changed, 77 insertions(+) diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst index e1b93ecedf..04b598390d 100644 --- a/doc/guides/prog_guide/rte_flow.rst +++ b/doc/guides/prog_guide/rte_flow.rst @@ -1398,6 +1398,28 @@ Matches a eCPRI header. - ``hdr``: eCPRI header definition (``rte_ecpri.h``). - Default ``mask`` matches nothing, for all eCPRI messages. +Item: ``PACKET_INTEGRITY_CHECKS`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Matches packet integrity. +For some devices application needs to enable integration checks in HW +before using this item. + +- ``level``: the encapsulation level that should be checked: + - ``level == 0`` means the default PMD mode (can be inner most / outermost). + - ``level == 1`` means outermost header. + - ``level > 1`` means inner header. See also RSS level. +- ``packet_ok``: All HW packet integrity checks have passed based on the + topmost network layer. For example, for ICMP packet the topmost network + layer is L3 and for TCP or UDP packet the topmost network layer is L4. +- ``l2_ok``: all layer 2 HW integrity checks passed. +- ``l3_ok``: all layer 3 HW integrity checks passed. +- ``l4_ok``: all layer 4 HW integrity checks passed. +- ``l2_crc_ok``: layer 2 CRC check passed. +- ``ipv4_csum_ok``: IPv4 checksum check passed. +- ``l4_csum_ok``: layer 4 checksum check passed. +- ``l3_len_ok``: the layer 3 length is smaller than the frame length. + Actions ~~~~~~~ diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst index 82ee71152f..cedb6fc7aa 100644 --- a/doc/guides/rel_notes/release_21_05.rst +++ b/doc/guides/rel_notes/release_21_05.rst @@ -84,6 +84,11 @@ New Features So that it can meter traffic by packet per second. Packet_mode must be 0 when it is bytes mode. +* **Added packet integrity match to flow rules.** + + * Added ``RTE_FLOW_ITEM_TYPE_INTEGRITY`` flow item. + * Added ``rte_flow_item_integrity`` data structure. + * **Updated Arkville PMD driver.** Updated Arkville net driver with new features and improvements, including: diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h index 203c4cde9a..5ccf5ba7ba 100644 --- a/lib/librte_ethdev/rte_flow.h +++ b/lib/librte_ethdev/rte_flow.h @@ -551,6 +551,17 @@ enum rte_flow_item_type { * See struct rte_flow_item_geneve_opt */ RTE_FLOW_ITEM_TYPE_GENEVE_OPT, + + /** + * [META] + * + * Matches on packet integrity. + * For some devices application needs to enable integration checks in HW + * before using this item. + * + * @see struct rte_flow_item_integrity. + */ + RTE_FLOW_ITEM_TYPE_INTEGRITY, }; /** @@ -1685,6 +1696,45 @@ rte_flow_item_geneve_opt_mask = { }; #endif +struct rte_flow_item_integrity { + /**< Tunnel encapsulation level the item should apply to. + * @see rte_flow_action_rss + */ + uint32_t level; + RTE_STD_C11 + union { + __extension__ + struct { + /**< The packet is valid after passing all HW checks. */ + uint64_t packet_ok:1; + /**< L2 layer is valid after passing all HW checks. */ + uint64_t l2_ok:1; + /**< L3 layer is valid after passing all HW checks. */ + uint64_t l3_ok:1; + /**< L4 layer is valid after passing all HW checks. */ + uint64_t l4_ok:1; + /**< L2 layer CRC is valid. */ + uint64_t l2_crc_ok:1; + /**< IPv4 layer checksum is valid. */ + uint64_t ipv4_csum_ok:1; + /**< L4 layer checksum is valid. */ + uint64_t l4_csum_ok:1; + /**< The l3 length is smaller than the frame length. */ + uint64_t l3_len_ok:1; + uint64_t reserved:56; + }; + uint64_t value; + }; +}; + +#ifndef __cplusplus +static const struct rte_flow_item_integrity +rte_flow_item_integrity_mask = { + .level = 0, + .value = 0, +}; +#endif + /** * Matching pattern item definition. * -- 2.25.1