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 BB6D0A0548; Sun, 7 Mar 2021 19:46:56 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 377F422A244; Sun, 7 Mar 2021 19:46:55 +0100 (CET) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2050.outbound.protection.outlook.com [40.107.94.50]) by mails.dpdk.org (Postfix) with ESMTP id CD39A40142 for ; Sun, 7 Mar 2021 19:46:53 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ubt66ckspJpPWPl9tkk0n8IlS5nLTInyL9v+XmFsQMW60omr0Rt9ZmgwP7kqNefxlu/TO4OnaMX1dI6Schij6zrcQPHN4SEkoqVDLF+cfQbzRjCfXNvaVV9TBRw+KF3S7ffAqVHdtidUTjuJqtfrQAnPwJgHiUHF7gFs3wKuILNuB5C1DH0HaeNRtu0IO1cNLhw0JXRsOg0iY1wQbh0VrhRAhjfiyk0wh2DKTiR2fK1qvDf9nJ72dm/uxCQJB+1HO8GU3qv7Lji37HUofM/CMmNJhP7ISv80eN3t4TUh6Wllfdl2u0UxB6vzevcB8ySmn5WeUGUVkBfXV5xbThdaQQ== 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=99sD6CkAs3vJOHvHEWxGmDbA9dn3E0wZaesrVVpldlg=; b=WmNLrqqIdJtBx2O1H9UFRWLku3GwJwHHAKFMxRVmMNVFFCakA9whkkmtcrf7OjQxbCQNdB/dZ2ZPLy9QmXsqSBItWwdPPfRXlMy56DGv/PivwtPkyP7QVnV0tdCQiPzYKkjF1iKpkCrtzGAItMlUs/A8heJ1t8vaKDvG31E2mJDjbyDqs76HsMptjYQVs+sfnGfaRivYbVDiTpcrkfbJ8LNxW7nsTauxM3X6glstsGgtt1r48Pr9o1KhD6XRRHUQz2qKADM0bx/Kve2369bueutOk8CC11QV996sqGLYOUhhJQKCPCm6fuCbZ3eNKJNTVYipUlcH22xrvkuCtsh5Hg== 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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=99sD6CkAs3vJOHvHEWxGmDbA9dn3E0wZaesrVVpldlg=; b=TzFEgiqFKQ4z+8Ct4Y+b8jyJ1utKV4Ry8+ayMFdSyhdEtCJATXRcePnXo+aYAckH6b/o4ZnQoaAJBNwYHhnsirb4bGczl3g9vdwZ8r6dEea9y0YkFim3+pU6ZhMwPRNDu046fxVXQYWggO1wRICvJt1hghQ++GCFjuzfHOv2+Lo= Received: from DM6PR12MB4987.namprd12.prod.outlook.com (2603:10b6:5:163::31) by DM6PR12MB3866.namprd12.prod.outlook.com (2603:10b6:5:1c6::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.18; Sun, 7 Mar 2021 18:46:50 +0000 Received: from DM6PR12MB4987.namprd12.prod.outlook.com ([fe80::f5ce:c5a8:6aec:e308]) by DM6PR12MB4987.namprd12.prod.outlook.com ([fe80::f5ce:c5a8:6aec:e308%7]) with mapi id 15.20.3912.027; Sun, 7 Mar 2021 18:46:49 +0000 From: Ori Kam To: NBU-Contact-Thomas Monjalon CC: Slava Ovsiienko , "ferruh.yigit@intel.com" , Andrew Rybchenko , "dev@dpdk.org" , "ajit.khaparde@broadcom.com" , "jerinj@marvell.com" , Ori Kam Thread-Topic: [dpdk-dev] [RFC] ethdev: add sanity packet checks Thread-Index: AQHXDgrGaABS+2Q53EeIxjHe/6avDqpuAH0AgARgq6CAAUn1gIAEjvWQ Date: Sun, 7 Mar 2021 18:46:49 +0000 Message-ID: References: <1614541699-99345-1-git-send-email-orika@nvidia.com> <1769565.OWqOAu9aEJ@thomas> <7146547.nIQmEXas8S@thomas> In-Reply-To: <7146547.nIQmEXas8S@thomas> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: monjalon.net; dkim=none (message not signed) header.d=none;monjalon.net; dmarc=none action=none header.from=nvidia.com; x-originating-ip: [147.236.145.126] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f488037f-669a-4339-e020-08d8e1995e29 x-ms-traffictypediagnostic: DM6PR12MB3866: 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:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KZLbKLB9dk4BQFQQh7eQvPgldhFiHs6Xj1ZxBXm6+CuY954eFKEJrGQ7f8RBCVkkTWMwSOebkg6JPuPl5sGxjI9CX0ExhyRwoqIoziD7B5mIVyxlLZqKWTrH3fArUxNWxYxqPDTf6CVUYq8IOZg3wqoiWoMbploUglFP5F6JomJalrMnioeieab68Gu6oa8Xp3a+52dr6xjrJwFosiPjGGj377UjtonWVzkmjgs0SKjJzHZ4cRnoXq7ZY8Ac1aCmwiY4zE8uwlRwvsvUBMhWnkAqu70rBuy+IGHjBA/82cCF/oGEykLrWmjclx4soSZ5QDHKu7T2+fR3fxI5ZT/CqWUGzOtkIaswOZ51GSYuUaTy9DWPYHznGK/pK+lQSeVcwdRVHi1YXGJylvIIpRxKYJLZYY6tFuwZpd+jb3gcoQBIsaESP3cxAOrktcRLvZq3uaoAMH0rWz1VwmO0HzBH2sYIkwWAmAno42Smk1MDC6wBBOwoNocaCNT7PHdiCm+MHLzAzKIOEDMUDPnaAddgpQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR12MB4987.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(366004)(376002)(346002)(136003)(6506007)(71200400001)(55016002)(8936002)(107886003)(53546011)(9686003)(66446008)(66556008)(54906003)(64756008)(478600001)(66476007)(6916009)(66946007)(33656002)(316002)(8676002)(7696005)(52536014)(4326008)(86362001)(76116006)(5660300002)(186003)(83380400001)(2906002)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?XYAcBStVKZNSPBrfBDkb3ejGdqD+xdEAUI6obdD4br+ZCvhUWpt18vENhdTS?= =?us-ascii?Q?C1f6shEbV9HxOek2EFgnwND8iKvixj1GmVpkkTLXjvl5IyNI/4VeT37JlNAg?= =?us-ascii?Q?KLL8smo2EU830rcgrnz3Q3MGfVEKtjrLA2QepKtyHbvoSs3FJN9jPFvCP3YU?= =?us-ascii?Q?vWa8XBJPivBk3Ns7Z2t8aM37zaZtMdz65k55JcS8abyiJdDMgARGJ/+RkBLZ?= =?us-ascii?Q?9QdIAa5WoIwuvkIMoJ3lyQMAGHd1jtwsAYmqdw/tlYux0wKhuil9fZyikOLl?= =?us-ascii?Q?WznSSuKjVS0MYvrH5vfJrzs5pKTzaKJ/2pXcCENeJ62kUUzLfqqvSKEIlb0V?= =?us-ascii?Q?N3J/JT2sMgNlGH6Ea4k7m+0r7rwrU+qHlVNWYlp1L1HyxDZ7veM7x+ByE7lH?= =?us-ascii?Q?h7nDma/grG7BTZwF5OjbWIeHTJgoGMbhqHINrvaO8UHj2XpQhSSNIP3HAwW6?= =?us-ascii?Q?QK/ecY2+PKznpOMtvOQBPvGFB+xyJe+LXh/9cbRO66W/dEqDMs/gu77XDuAG?= =?us-ascii?Q?uAp4nDZgiYlO4vqnD1I2IjPG/o68NMCVW7SHTO2Whr8/ylkMV62jEJ8k6KJk?= =?us-ascii?Q?FA1zGFFjn2+kidtTz73z01WbY2mGpPfQcJ6aXpgnqwOpRgND0eIuc6cuAJff?= =?us-ascii?Q?jrn9KCbsfryALCVgVHTWUxPrRxaAs1SN7+T9TzlecrnRTE+ysw5Ol8SiXrrk?= =?us-ascii?Q?5O5YvffeNHVSZRUdhZxm5gqtuBUfxlyLy9O/zXA0AafzzhXkHInJJ7dHnaKX?= =?us-ascii?Q?Zdd3vXzxYLMNV+1AsEIhaDseVAsN+jbgSkImN+Yc2wIcNOJxLTk21CE3coCu?= =?us-ascii?Q?u7clwKeJzGDJtwiWMnmeopn4o0RbqGqh+tFf0AmsFjK7WbpCuuVA3enKiVID?= =?us-ascii?Q?zjfyqwFA8J8F/s7QccYT8k8AT50RfVdV9jJgyoNSfwyqqYI2vQ3M9nOFC0qD?= =?us-ascii?Q?VYwGZ7mckyadBiJYNHbzOmG2TXOSw2cvJW+QlmfVLjrh4OvfPLdTsdNBtTEK?= =?us-ascii?Q?9e3lCQ1b7WMJ/k17HgcA12rnB2IZybDL3AqJUeDPWlrlvs/CKwkWt3kiekWM?= =?us-ascii?Q?0Twosw4HnfoBuv5EytDSxe6GpCBd/ZqcKoFpssrFWKN7rXKrGqRc+gcyCZe7?= =?us-ascii?Q?NCZ52l9I0sHg66hktDPsK8KeSjykyI0sxbFSqrLgPZ27q01Ti0GKz91JG8o8?= =?us-ascii?Q?yid3CuBzSYsZOX5vm3VvLmwfd9oE/CKJnq58AMMzJLjWesZ+10a6kBbQ0clS?= =?us-ascii?Q?rrH74qP9aMcRyLPGAp6GkdEKJwr1fY2tCMJnFUv/Bo01BRkt+hp/KdmW5gmm?= =?us-ascii?Q?ajBvaU1B0zJQuKDRX0KVg8Wp?= 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: DM6PR12MB4987.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f488037f-669a-4339-e020-08d8e1995e29 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2021 18:46:49.7674 (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: Ulbts41woIb7BdCyTwtTB+6gvMu3aoDCu+7+OVLa93FLPVHW/XA3Ae3pV2LobE8nNbLdBpHo0NwEQ8+Xd/DbrQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB3866 Subject: Re: [dpdk-dev] [RFC] ethdev: add sanity packet 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" Hi > -----Original Message----- > From: Thomas Monjalon > Sent: Thursday, March 4, 2021 12:46 PM > Subject: Re: [dpdk-dev] [RFC] ethdev: add sanity packet checks >=20 > 04/03/2021 11:00, Ori Kam: > > From: Thomas Monjalon > > > 28/02/2021 20:48, Ori Kam: > > > > Currently, DPDK application can offload the checksum check, > > > > and report it in the mbuf. > > > > > > > > However, this approach doesn't work if the traffic > > > > is offloaded and should not arrive to the application. > > > > > > > > This commit introduces rte flow item that enables > > > > > > s/rte flow/rte_flow/ > > > > > > > Sure > > > > > > matching on the checksum of the L3 and L4 layers, > > > > in addition to other checks that can determine if > > > > the packet is valid. > > > > some of those tests can be packet len, data len, > > > > unsupported flags, and so on. > > > > > > > > The full check is HW dependent. > > > > > > What is the "full check"? > > > How much it is HW dependent? > > > > > > > This also relates to your other comments, > > Each HW may run different set of checks on the packet, > > for example one PMD can just check the tcp flags while > > a different PMD will also check the option. >=20 > I'm not sure how an application can rely on > such a vague definition. >=20 Even now we are marking a packet in the mbuf with unknown=20 in case of some error. Would a better wording be " The HW detected errors in the packet" in any case if the app will need to know what is the error it is his responsibility, this item is just verification for fast path. If you have better suggestion, I will be very happy to hear. >=20 > > > > + * RTE_FLOW_ITEM_TYPE_SANITY_CHECKS > > > > + * > > > > + * Enable matching on packet validity based on HW checks for the L= 3 and > L4 > > > > + * layers. > > > > + */ > > > > +struct rte_flow_item_sanity_checks { > > > > + uint32_t level; > > > > + /**< Packet encapsulation level the item should apply to. > > > > + * @see rte_flow_action_rss > > > > + */ > > > > +RTE_STD_C11 > > > > + union { > > > > + struct { > > > > > > Why there is no L2 check? > > > > > Our HW doesn't support it. > > If other HW support it, it should be added. >=20 > It would be an ABI breakage. Can we add it day one? >=20 Will add reserve, since this is bit field there shouldn't be any ABI break. > > > > + uint32_t l3_ok:1; > > > > + /**< L3 layer is valid after passing all HW checking. */ > > > > + uint32_t l4_ok:1; > > > > + /**< L4 layer is valid after passing all HW checking. */ > > > > > > l3_ok and l4_ok looks vague. > > > What does it cover exactly? > > > > > It depends on the HW in question. > > In our case it checks in case of L3 > > the header len, and the version. > > For L4 checking the len. >=20 > If we don't know exactly what is checked, > how an application can rely on it? > Is it a best effort check? What is the use case? >=20 >From application point of view that packet is invalid. it is the app responsibility to understand why. You can think about it that in any case there might be different counters for different errors or different actions. For example, the app can decide that incorrect ipv4 version should result in packet drop, while incorrect len may pass. Maybe we can list all possible error result, but I'm worried that we may not cover all of them. On some HW there is just one=20 bit that marks if the packet is valid or not. >=20 > > > > + uint32_t l3_ok_csum:1; > > > > + /**< L3 layer checksum is valid. */ > > > > + uint32_t l4_ok_csum:1; > > > > + /**< L4 layer checksum is valid. */ >=20 > What worries me is that the checksum is separate but other checks > are in a common bucket. > I think we should have one field per precise check > with a way to report what is checked. >=20 Pleas see above comment, Current HW doesn't support such fine grain detection, so adding bit will force the user to select all of them, in addition since the HW has some internal=20 checks it is possible that the reject reason will be un related to the L3, for example some HW may not support more then two vlans so in case of 3 vlans may report bad L3. Best, Ori,