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 C0A53A0547; Sun, 18 Apr 2021 10:15:46 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 96399410D8; Sun, 18 Apr 2021 10:15:46 +0200 (CEST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2084.outbound.protection.outlook.com [40.107.220.84]) by mails.dpdk.org (Postfix) with ESMTP id F4009410D7 for ; Sun, 18 Apr 2021 10:15:44 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RUdRoSiVACK90SJpzZO7UHvl0FRrNs1gy5uCKkQCvGvCnTI8uEU9ikqo5y/rMmyNH11EZ4UVeRRyaeYu8hYBnI+2TOFY7tqpEAdsQgWyYXNEh3F2jwWFYmHLdWBw8kuNM7BiX24rp6tal9uN3JRsAnOoRZxBKctzkX2EekZd6fvbWSkXfm+7JSBMy5hZ8ZCf11/V8nkLVhC46xbXcCIZAllL0Cw5d31DyPQSY9YwdxHAd+jP3GRdOwoyvHuOmIwOyC/MsMFh7ewJZQqCk9me9cVv4K/v7d7ioIyxEGFiZaQENosUfPdiyybzwKNBjo26u4jBVy1pv5OpFwjCsbw25A== 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=2M1HdVjGYtwCE9oMrnDq0JRrXqcAo5UgO4BzV5XEny0=; b=ay5TO19ZKGfUxWYssowWMopqxthBHPkoEAwIq2ckbCzJobor+RM/7qmBXtzmFW4ySUdNHTEJENr7FMbWNW9YT0okcBrMA43UCqwzrsDKKzqQ0qZVuP8BSm9BXGzPKsR2DkluNXECJmXaOJcNuzY3VVY/9kqgLV8xtYYS4V5DQyMS0hUkSDl8nAD7WkM6wNBfkTbJwLwWfg566s804DkuG0vEq4tFpeEJFal1bGSS/Wno+9ofBk7tmQ8rHqeTsIlayLC9HOmMmijWjM7Q6Yzt8AJDOO054S4VdXR6I6g/PFWnkyFmLgddBpR+6bpWYFUjrxA4qkTfLqOEbUXej9DlQw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; 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=2M1HdVjGYtwCE9oMrnDq0JRrXqcAo5UgO4BzV5XEny0=; b=TDw8JxCWzOri9nPDOu9F4DTSbWWH37pHtmTwMf8fQuMciarg7GE9H5kwvJ3NtrgoA2Ecrbz5DLshQtKKry1HT8GcT8PpJW2HltpjwVpg2FU8wKRCN8ctNCg0od7T9XUhw8glK3IJ7KMiHFXkeSW3V7LF5zwLVoD7cKAdAn0GF5LOUAAfUiI38Jf2jq1gdgMIa5e32vTxp78w1g4KpZjf+WzuQuAnKJ6RyuH1NR3AXsNaczS5Mzs1SlSbLPTND3dhJkCE/JduL1KAfgj/GYcqev72m2R4nSzWrXQ1k8jaCKEDQ6bHJNgwFLXjkSmY9o3n16SDnoDxS2avTPJxl/uwLQ== Received: from BY5PR12MB4834.namprd12.prod.outlook.com (2603:10b6:a03:1b2::17) by BYAPR12MB4741.namprd12.prod.outlook.com (2603:10b6:a03:a2::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.19; Sun, 18 Apr 2021 08:15:41 +0000 Received: from BY5PR12MB4834.namprd12.prod.outlook.com ([fe80::45ab:9d36:e3f8:40e2]) by BY5PR12MB4834.namprd12.prod.outlook.com ([fe80::45ab:9d36:e3f8:40e2%3]) with mapi id 15.20.4042.024; Sun, 18 Apr 2021 08:15:40 +0000 From: Gregory Etelson To: Ori Kam , NBU-Contact-Thomas Monjalon CC: "dev@dpdk.org" , "ajit.khaparde@broadcom.com" , "andrew.rybchenko@oktetlabs.ru" , "dev@dpdk.org" , "ferruh.yigit@intel.com" , "jerinj@marvell.com" , "jerinjacobk@gmail.com" , "olivier.matz@6wind.com" , Slava Ovsiienko , Matan Azrad , Raslan Darawsheh Thread-Topic: [dpdk-dev] [PATCH v5 1/2] ethdev: add packet integrity checks Thread-Index: AQHXMUjZ0xo58t7ZnEaEhzw+tvn6M6q1yy2AgAD6pYCAAyoPAA== Date: Sun, 18 Apr 2021 08:15:40 +0000 Message-ID: References: <20210414160930.14928-1-getelson@nvidia.com> <20210414160930.14928-2-getelson@nvidia.com> <4965931.SumkqlMz0V@thomas> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nvidia.com; dkim=none (message not signed) header.d=none;nvidia.com; dmarc=none action=none header.from=nvidia.com; x-originating-ip: [176.230.227.114] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0cda3e06-b597-47a6-e905-08d9024227c6 x-ms-traffictypediagnostic: BYAPR12MB4741: x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: I7xsoXrf1FGz+9dEsQeTND3N6ZZlNCmZCD4O+wamGxWZRBQ0hMr45Z9+yVzsJ8k1YadQcp59slt9j5GrIyXGhWRejSvEsreceJ8jrGLVhLimQyVb/cBJBcsQRclrVLW7+KljFg8j9SxqwZzqgpEQrDALWArzpEg9P4ZXkwdCWsSo9SVk1Ko1MpKwF6cbQ1Ql6q3ZNeJxYEUYcA2dezDqRjBzz3Wk1k6gcBVP51J6ey+JLVMgNfwoq8VcVxyScqkP3zf3C+mvB+45hFmOlMuaQihPfZ6YU+nvhABEt8CQpdFOsQBRwYvNGKBhrLlzWMCrcEviXJVsKFuTKrWf1ohQcVFQJ1hcvocWEZduQHPPoUE9ShXYBd35C9G7anl7OWmeDg90PPCg6XL48KQHcKp73lsTig5YCurHDRjTaz2tAHvSuw1bzBdM2uARPvqK8DRKYnlsYGF/Yc4qqA/0l4A105Bmonzw2eywzoLSiSEQMmttAhaxp9l1lPdAwpgEWIPAssNb5cLZYyJq5h7tVQMdZAdkWcALru5DDbOWrsE8FU7tSzDExgD3/O3ZDvCPaZOP+sU9i0/rtBWI2PInvLLlQOhLhsQGSTEcW8nzaAtZjVA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR12MB4834.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(396003)(376002)(39860400002)(346002)(8936002)(2906002)(5660300002)(478600001)(54906003)(6506007)(7696005)(52536014)(83380400001)(110136005)(55016002)(9686003)(4326008)(33656002)(76116006)(66446008)(64756008)(26005)(66556008)(66476007)(66946007)(71200400001)(122000001)(186003)(8676002)(107886003)(86362001)(316002)(38100700002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?mD0gHTeJU0NrsnKH6YF+FQV5tjVLL2Z32BG5BdD9mJflayc+nvUKiLEad0d6?= =?us-ascii?Q?l0oO1H9AhSyQVHARI5AW8GDSzqqiO7OVRnKTsu2EjG3E3svhyO6blhl7odhv?= =?us-ascii?Q?Ueb93NARhNZrVbzB0+v3sQNbdxJSf5uJSXzAOS9uuIPwH3xZ40DZkKvcn975?= =?us-ascii?Q?qPliiHSEVAp3duz9pKg/wTX4a0LeG7uTCzj4TgGHtkxbBBfRaeYaKvk/d2pF?= =?us-ascii?Q?NfY3aN84PNyRiAEPcXDwNFgGUebz7BN1NZ7BgfQAqqiv1Y3AYd1TbdlmEzEO?= =?us-ascii?Q?mnYhT8SLu8xkY7xGlHrYY3KKTRb224tCnfxIP12Xti9GLBFw8nhZrIlkIFXQ?= =?us-ascii?Q?pZzVh8Qxv5Ff3QQoE30zbuvNaaCH+Um2Z9nQVx0Xg1VZC920kYUy+KMIBmAU?= =?us-ascii?Q?dR5mV0XeHvI5J4oIX0YCyHvKT91dgQsoQNAwFheEMfK9vv6Bv00dvKZFpaty?= =?us-ascii?Q?6uOhhCbmAxCqhS6BlV7nDWg6BzXw0KYanRgCzLJaUtpxycHRV1H+wBUSrAec?= =?us-ascii?Q?GRG3eTTJTTvSh03RBaP+D6/kkHAOFUUcGfL+Trf19ESplDPXqCyPkiEWIBVh?= =?us-ascii?Q?TYOinvHye0SGgOVVTEZrkAYOUvKEC4bXJfALHvJX6ljjYEhY0rVlNySlRxUm?= =?us-ascii?Q?pCDioO5T1kvqG2P+GC7Z1icOfnLlF3P+65sjV04qPRvr4pnxnGbQJH4WIvyG?= =?us-ascii?Q?JYg2RVVDPSIaqCk396b/ptLTx9gW4qtt6/gfIxdZqPGd7n86yPbJdPutFqkx?= =?us-ascii?Q?sKohYdGdq7C3veOIgQXGNbqhssiqyZjwhOgt4xDGo8jcU9VXvhFSQgBYDiiY?= =?us-ascii?Q?RDVffLFOP46HotRkuaPRAKHN+co7AFQ6sjyHzD1DT3vQZgAaSJJqiq7K9Rgh?= =?us-ascii?Q?syoyaH8wiXBqS6fWsUmMNJgJ47AhtQKfA8oKsuhxKbwhNrJ71DKAlQTyDJzw?= =?us-ascii?Q?TrtKxZIfcC6HZJKTnaherO7KJco22dcDIfRGdc9iEdX9jK9czTfNAocARbVi?= =?us-ascii?Q?QzFTiiV0eALKgDvCIqdEeiGCZe4R/sjDVAXtJ+Z5GKk7pJG5EzzfnXgcgHnc?= =?us-ascii?Q?Nc69putT1Xn/rHjTevZweg1+uRC9BE0eRDsJPF+W3Z4Hz0+nwdSFvi7Pjhzz?= =?us-ascii?Q?BATsveklDm3oL1UycvetV2/OFbiyD84u5Qh2cV2rrGv3YUCXHa363gHtUsgO?= =?us-ascii?Q?ILvf2MeHQ75No6Ibzp7qCdQ6i/s2+MoA/7k6oWfk08gDPV6CoAdGDqfvevXb?= =?us-ascii?Q?qouW2gDtdbixJ2WnfcwT9h2nqZWHEM16IOV+3lbiX82e9BK8EHyE7XGlmtwm?= =?us-ascii?Q?O1AHFSfyi/mXvTq5jW9dO2DH?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4834.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0cda3e06-b597-47a6-e905-08d9024227c6 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2021 08:15:40.5931 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KTaK2mYt2CxZULl9ca6+eI6B4xAKBQFlnyPgRdp9EZ/tq7hJ+W2lKH4Bd0ydhH95j/1DEcFts3w8/NnLXhiNaA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR12MB4741 Subject: Re: [dpdk-dev] [PATCH v5 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" Hello Thomas, Please see my comment on the use of RTE_STD_C11 below. Regards, Gregory. > > > 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) a, and add default flow > > > > There is a typo here. What should it be? > > > Simply remove the a. >=20 > > > (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 considure the following (in no specific order): > > > > s/considure/consider/ > > >=20 > Will fix. >=20 > > > 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 possi= ble > > > 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 th= e > > > frame len. > > > > > > Example of usage: > > > 1. check packets from all possible layers for integrity. > > > flow create integrity spec packet_ok =3D 1 mask packet_ok =3D 1 ..= ... > > > > > > 2. Check only packet with layer 4 (UDP / TCP) > > > flow create integrity spec l3_ok =3D 1, l4_ok =3D 1 mask l3_ok =3D= 1 > > > l4_ok =3D 1 > > > > > > Signed-off-by: Ori Kam > > > --- > > > doc/guides/prog_guide/rte_flow.rst | 20 +++++++++++ > > > doc/guides/rel_notes/release_21_05.rst | 5 +++ > > > lib/librte_ethdev/rte_flow.h | 49 > ++++++++++++++++++++++++++ > > > 3 files changed, 74 insertions(+) > > > > > > diff --git a/doc/guides/prog_guide/rte_flow.rst > > b/doc/guides/prog_guide/rte_flow.rst > > > index e1b93ecedf..1dd2301a07 100644 > > > --- a/doc/guides/prog_guide/rte_flow.rst > > > +++ b/doc/guides/prog_guide/rte_flow.rst > > > @@ -1398,6 +1398,26 @@ 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). value of 1 > > > +means > > outermost > > > + and higher value means inner header. See also RSS level. > > > +- ``packet_ok``: All HW packet integrity checks have passed based > > > +on the > > max > > > + layer of the packet. > > > +- ``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 len is smaller than the frame len. > > > + > > > Actions > > > ~~~~~~~ > > > > > > diff --git a/doc/guides/rel_notes/release_21_05.rst > > b/doc/guides/rel_notes/release_21_05.rst > > > index a0b907994a..986f749384 100644 > > > --- a/doc/guides/rel_notes/release_21_05.rst > > > +++ b/doc/guides/rel_notes/release_21_05.rst > > > @@ -168,6 +168,11 @@ New Features > > > the events across multiple stages. > > > * This also reduced the scheduling overhead on a event device. > > > > > > +* **Added packet integrity match to RTE flow rules.** > > > > Please remove "RTE", it has no meaning. All in DPDK is "RTE". > > >=20 > Sure. >=20 > > > + > > > + * Added ``PACKET_INTEGRITY_CHECKS`` flow item. > > > > It is RTE_FLOW_ITEM_TYPE_INTEGRITY > > > > > + * Added ``rte_flow_item_integrity`` data structure. > > > + > > > > This text should be sorted before drivers. > > >=20 > Sure. >=20 > > > --- 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. > > > > That's a bit fuzzy. > > Do you mean some driver-specific API may be required? > > >=20 > I know it is a bit fuzzy but it is really HW dependent, for example in ca= se of > some drivers there is nothing to be done. > In other cases the application may need to enable the RX checksum offload= , > other drivers may need this cap be enabled by HW configuration. >=20 > > > + * > > > + * See struct rte_flow_item_integrity. > > > + */ > > > + RTE_FLOW_ITEM_TYPE_INTEGRITY, > > > }; > > > > > +__extension__ > > > > Why extension here? > > If this is because of the anonymous union, it should be RTE_STD_C11 > > before the union. > > Same for the struct. > > > O.K >=20 The RTE_STD_C11 macro fails compilation on=20 RHEL-7.9 with gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) > > > +struct rte_flow_item_integrity { > > > + uint32_t level; > > > + /**< Packet encapsulation level the item should apply to. > > > + * @see rte_flow_action_rss > > > + */ > > > > Please insert comments before the struct member. > > > O.K. >=20 > > Instead of "Packet encapsulation", isn't it better understood as > > "Tunnel encapsulation"? Not sure, please advise. > > > I have no strong feeling ether way, so I don't mind the change if you thi= nk it > is clearer. >=20 > > > + union { > > > + struct { > > > + uint64_t packet_ok:1; > > > + /** The packet is valid after passing all HW checks. > */ > > > > The doxygen syntax is missing < but it will be fine when moved before. > > > Sure. >=20 > > > + uint64_t l2_ok:1; > > > + /**< L2 layer is valid after passing all HW checks. */ > > > + uint64_t l3_ok:1; > > > + /**< L3 layer is valid after passing all HW checks. */ > > > + uint64_t l4_ok:1; > > > + /**< L4 layer is valid after passing all HW checks. */ > > > + uint64_t l2_crc_ok:1; > > > + /**< L2 layer crc is valid. */ > > > > s/crc/CRC/ > > > O.K. >=20 > > > + uint64_t ipv4_csum_ok:1; > > > + /**< IPv4 layer checksum is valid. */ > > > + uint64_t l4_csum_ok:1; > > > + /**< L4 layer checksum is valid. */ > > > + uint64_t l3_len_ok:1; > > > + /**< The l3 len is smaller than the frame len. */ > > > > s/len/length/g > > > O.K. >=20 > > > + uint64_t reserved:56; > > > + }; > > > + uint64_t value; > > > > double space > > > Sure. >=20 > > > + }; > > > +}; > > > + > > > +#ifndef __cplusplus > > > +static const struct rte_flow_item_integrity > > > +rte_flow_item_integrity_mask =3D { > > > + .level =3D 0, > > > + .value =3D 0, > > > +}; > > > +#endif > > > > I'm pretty sure it breaks with some C compilers. > > Why not for C++? > > I see we have it already in rte_flow.h so we can keep it, but that's > > something to double check for a future fix. > > > Just like you said this is the practice used already, >=20 > >