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 EF0D3A056A; Wed, 10 Mar 2021 18:47:18 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8119622A3AF; Wed, 10 Mar 2021 18:47:18 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id BED2F40F35 for ; Wed, 10 Mar 2021 18:47:16 +0100 (CET) IronPort-SDR: cuRBK/vJnMWx/y3SlQuzmFbHcsYU3Rr7X4fmiVFY1C3O1Aq8drePo30fubd1YZXbRasjXv727S HWtDTM688Lzw== X-IronPort-AV: E=McAfee;i="6000,8403,9919"; a="187886930" X-IronPort-AV: E=Sophos;i="5.81,237,1610438400"; d="scan'208,217";a="187886930" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Mar 2021 09:47:15 -0800 IronPort-SDR: ViR6wT9BzouCa1ugdYMIcDC9u+fEfAd15TEzZwEdQZbxEli07tKHz35R58qobx1eHY/tuw9COU yT+uZUo5r8iw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,237,1610438400"; d="scan'208,217";a="431299085" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by fmsmga004.fm.intel.com with ESMTP; 10 Mar 2021 09:47:15 -0800 Received: from orsmsx609.amr.corp.intel.com (10.22.229.22) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 10 Mar 2021 09:47:14 -0800 Received: from orsmsx602.amr.corp.intel.com (10.22.229.15) by ORSMSX609.amr.corp.intel.com (10.22.229.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 10 Mar 2021 09:47:13 -0800 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Wed, 10 Mar 2021 09:47:13 -0800 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.174) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Wed, 10 Mar 2021 09:47:13 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EKayuoyeLAOQjM1XbWE/JzfhoTJIufYBiuLnCqioYIE8Ge+7hLMIRrQLNnwvPDxekJrJY447mjn1zSyqPoDQzlJYrTAxeSH8aJc+h8Na6590JbkgLjiePWf4071bujWSR7yPud5eQ+0f1tqrGXA1Jrd0eylQUYGLv9IzIj3eV7Zb8WXG1X9iUX//Dg01YivlwIdVMFp+Bc39i7LAbVkdo20OSb8OrbXLTbF2VoT8RL0Yg4PKgUBAcIq7/bK9acUv9neIS18jRpR7nfXTmZvXOQdOTbks0nhVLM3gpavuwNwSK0pCccA8RgxfKwxwDcpJJZDw7zw+WdC31NWsoL8zeQ== 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=EcTCznZpGG1aj8M/8qyrVJcYCJolhdOooRNNmzv3qWk=; b=MO8gXrMlvS+WpQBPOWYJ1VmTl01F8QjSUZpe1czq799ncDdIBGU5tBI/Qn0A0aB83b/gfnqNWITsH0tGRRNMMkINkDbdai3+EfTeYWA6Mb4DS6Xswr+HRfQ3yjsqB3ligFHDXb2FtDxMr8suNmHxiBY6melOOr/D81jMAwDW6+wERfcOL5KOfpy7yyi1piwOJ2/SL0ZhvHpQvRUtNwIjf+++kx6/Wk0/44gtNrOpi0OKSEgT4CMgGySE1dByrnY71B7JJhMnxbgi9vKSFrvPy2fUb6PLH1DtUQwaF00pJ8QS6nh1GM13YcnfUBm11Z4jX5X+pqmk3085GUrc9C/SDA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EcTCznZpGG1aj8M/8qyrVJcYCJolhdOooRNNmzv3qWk=; b=jmDkacOYOfulaS93KX/mP5cPeMNfSilCCTs/tQ5Saz4lvoVY2yfvWsVv0cDUWCQ9yAFjQx7Xm0eejfBGj7sv66kA0kN4pLqVrWZaXtOEtxFStDB17ppywwmXiGOlDVeppc+LBoAy5NYILkAoPSc++LaG/1D3naHtKUgFMVSdpBI= Received: from SN6PR11MB2880.namprd11.prod.outlook.com (2603:10b6:805:58::15) by SN6PR11MB3390.namprd11.prod.outlook.com (2603:10b6:805:c0::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.28; Wed, 10 Mar 2021 17:47:10 +0000 Received: from SN6PR11MB2880.namprd11.prod.outlook.com ([fe80::1d31:1052:7c28:cd7c]) by SN6PR11MB2880.namprd11.prod.outlook.com ([fe80::1d31:1052:7c28:cd7c%5]) with mapi id 15.20.3912.030; Wed, 10 Mar 2021 17:47:10 +0000 From: "Trahe, Fiona" To: Linfeng Li , "dev@dpdk.org" CC: "Griffin, John" , "Jain, Deepak K" , Steve Rizor , Emil Meng , "Kusztal, ArkadiuszX" , "Doherty, Declan" Thread-Topic: Behavior inconsistency in QAT PMD code Thread-Index: AdcV05ABbqh313VRTGmUk1qPpgwehgAAUD3Q Date: Wed, 10 Mar 2021 17:47:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 authentication-results: qti.qualcomm.com; dkim=none (message not signed) header.d=none; qti.qualcomm.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [109.76.68.72] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 12ee9b28-d898-4f25-331a-08d8e3ec880a x-ms-traffictypediagnostic: SN6PR11MB3390: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,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: vNZOvUftXSEVJhDlehtn3zQCzrMYsOHkedj4k1LejoF5t2M3UzuV48Q3Wqe1+CCVJwFofurD4RcqJSsjJp6TTX+7t8EtNg7yPDGr/7HqFWTTY/3ZxdLLT1GQCzuw74GWOpIVxbiISY8JalNQltzMls7/ygBSdi6wOhOTZWlDjva3Gs/80qhmafK6q8D6N24iGyEN7vwh/UzHFvwAE+NjA5Rwiz56NLv+yFtl5vG9ltfYaJsInmpUnqQWfyIB3+Bu/tyLrTf1bYvKUIyRpn5evJCaS3ioyFs9cuZ3tcJVaVmmRNE2Ymmphjrs97S0GAiYTpfrnmyE+RCKBsqVSyzI87VM+1L+FbqtDTy+vvD78SGbjEJs5nSWrNaJtaE65v54HhusXPm7hePHd+gGgpw1XJ0d7Mw3yKd55Y0aMcfs9DHbdtx6RqakNjwMxojLXG/htToXpNRTqKkek2wvHRbwOp90ylBtHKko0g4HoxvaKfl0Ze2I8qPg1YlUcWWSGSJLNAqjT8rl301wRfV9m+bTcOCvapPtIj/vyAzLxEwuAG4/hnGHwKw1tEofMShVIvbUsXz51dL54va7nY978rFvHIRRgi400cxj+LmaF8ulKy4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR11MB2880.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(346002)(396003)(136003)(376002)(316002)(33656002)(5660300002)(54906003)(8676002)(4326008)(107886003)(52536014)(26005)(166002)(110136005)(7696005)(8936002)(6506007)(86362001)(186003)(66556008)(76116006)(83380400001)(66946007)(66446008)(966005)(71200400001)(9686003)(478600001)(2906002)(55016002)(66476007)(53546011)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?sxYuHVzbFeOMi8m4YHVdE7i1a+N6EiRvKYWktZ/ocmRN4wVARbQ40LxZjg5p?= =?us-ascii?Q?382q5lRc0YafIpToHrZHdHMKqtiymKMh2mp7GbaGB/aP5w9Hjj9sOwN3jwtV?= =?us-ascii?Q?fl7Bx6CpHQ+WQJBIBreUuNM/+r7b/K4I7ql6P1KkeX4VIHDdbXTOLTmGa1sp?= =?us-ascii?Q?LUqgUvRFqHsrVwA7+p3nJAIRq81RDN3MzwPA9oo/hmuA/KgD/FYKhkBtX443?= =?us-ascii?Q?70V0XsDJSrNbUUwHBsYDJeOKnpGiE+7opAzJk93+77mC13S0INb2UGxuUz6e?= =?us-ascii?Q?foe927pIQP6aGdrzScsNzQHKJl1/oUtYfumOC0JBqA5IawuVCtJOzU4gunUA?= =?us-ascii?Q?PABP/rCA9Q02I0aIm0ysODhuxg7D+MVJHXWMhMdGTciP5ZElbmAicR6D/9/m?= =?us-ascii?Q?mZVpk/dX3s9EoATCkWM31TAueP6ijR6Rz64snJDBYJc4R8/CVeD9PD4CiFWh?= =?us-ascii?Q?XFQzbIozKVbs80DFuMlAl5vDLDTzKi/5dOmKrKbRR82zxwncN93K1325AVYW?= =?us-ascii?Q?GrmMdfOqjmouJMpqKKPxVACNKQS5XsaWdhKWsnnCBz6Vr598wvdI4+mSBFsp?= =?us-ascii?Q?hYDKVnGbcxZUtN8JhN2SbR//P3OrSF7zph/3S8+sTQct4WyQxegtWjxay4iF?= =?us-ascii?Q?OTYVPl/ZrOZCs9AWbCk/OYPt8qZrTSVopflDNciLQwkA35EiUTryFZpvEivH?= =?us-ascii?Q?PXop1rT3I79NKuL6yUWgTS5wPJ2WgmU12nGxIFPfMjYsSSF2ho6/r92QMv05?= =?us-ascii?Q?u+LrmC44kSG8D7E+SvOK0R+ngHrn5thvTEcv/sABXJUbrlIRsggA/VefarTi?= =?us-ascii?Q?8I6MoWQ5tQlEWD9ogE6J7KsF2BsL5tXTN4VrEXNh5N3/5VJqmgbGIsi7FtL/?= =?us-ascii?Q?pPIQVnP9PdXhLF7P42jJ4Uxw0T6cT2elaRnLVxBp2DA7Dz3zGvRHHoLPing9?= =?us-ascii?Q?ZOkLAgl5TJxSCBacE7ET9JLrwDvjaEk999y5f2VqVJrxwqAxQpa9lSLx5FvJ?= =?us-ascii?Q?VaKINjxWYMhXzTcIRWEd3yxcbgQZz4bnTgOSH7NcNviVMya5n94+CwWcQ/S3?= =?us-ascii?Q?cR1Lcbc0juVfITVCD1bQIQHtio86sh5/tP77PPVH1Dr1CNWVcgN3F4MGDQno?= =?us-ascii?Q?ZGNdJplgzXiotuxGPJv+ir91QHa57cbFHR/12ZdBVMvvC5RkWKQUKtOMvX7z?= =?us-ascii?Q?92++Bipezei05ycPpobluB+A13hlC0FqyAQC2YwaTV+Z+k2KMTdhrOM35o3i?= =?us-ascii?Q?EHYmQSD5A974PAcJ5QoBlgDBWuoe2K0Vjzut97iBUNVgb/9ThMwv8KfZ4h0x?= =?us-ascii?Q?73M=3D?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR11MB2880.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 12ee9b28-d898-4f25-331a-08d8e3ec880a X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2021 17:47:10.6282 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RQQOPGWWLwBVf/wOKFnzB059LgQvEUtqwAVRxtufbbFKGj6AgVNBnD+8JOX90Slyvx7sBdN2EkBmzvlBW+IHTg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3390 X-OriginatorOrg: intel.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-dev] Behavior inconsistency in QAT PMD code 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" Including Declan and Arek. Hi Linfeng, Thanks for raising this. I passed it on yesterday to the team, they are inv= estigating. Regards, Fiona From: Linfeng Li Sent: Wednesday, March 10, 2021 5:38 PM To: dev@dpdk.org Cc: Griffin, John ; Trahe, Fiona ; Jain, Deepak K ; Steve Rizor ; Emil Meng Subject: Behavior inconsistency in QAT PMD code Hi, We believe we found a behavior inconsistency based of different source mbuf= layout in the QAT PMD code. file link: https://github.com/DPDK/dpdk/blob/main/drivers/crypto/qat/qat_sy= m.c The inconsistent behavior happens when: * symmetric operation * out-of-place operation * encryption * do cipher + not do hash * cipher offset is non-zero inconsistent behavior: * scenario 1: When SGL is disabled; or when SGL is enabled, cipher o= ffset is smaller than the length of the first segment of the src mbuf chain o behavior: In dst mbuf, characters loacted in cipher offset is not copie= d over from the src mbuf. ||| data_len:2 ||| ---chained---> ||| data_len:66 ||| src mbuf SGL: seg 1: 2 bytes(cipher_offset) seg 2: payload ||| data_len:2 ||| ---chained---> ||| data_len:66 ||| dst mbuf SGL: seg 1: 2 bytes copied over seg 2: ciphered payload * scenario 2: when SGL is enabled, cipher offset is larger than or e= qual to the length of the first segment of the src mbuf chain o behavior: In dst mbuf, characters loacted in cipher offset is copied ov= er from the src mbuf. ||| data_len:68 ||| src mbuf LB: src: 2 bytes(cipher_offset) + payload in single mbuf ||| data_len:2 ||| ---chained---> ||| data_len:66 ||| dst mbuf SGL: seg 1: 2 bytes untouched seg 2: ciphered payload Actual packet data: Src mbuf 0xcc 0x33, 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 = 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20= 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 = 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f 0x40 = 0x41 dst mbuf: in LB, out SGL (scenario 1) 0x00 0x00 0x9c 0xce 0x6e 0x14 0xee 0xe2 0x57 0x74 0xb4 0x71 0x7e 0x8e 0x60 0xe3 0xe9 = 0x76 0x96 0x88 0x55 0x51 0x13 0xda 0x5e 0xfa 0xcf 0xc8 0x34 0xa3 0x6c 0xd5 0xbb = 0xbb 0xd8 0x3a 0x6f 0x9e 0x74 0x42 0xa8 0x46 0xed 0xde 0x2c 0x98 0x83 0x49 0xde= 0x25 0xa8 0x62 0x3a 0xa1 0x84 0x3e 0x00 0x7b 0x0d 0x3e 0x80 0x5f 0x49 0x20 0x6e = 0x08 dst mbuf: in SGL, out SGL (scenario 2) 0xcc 0x33 0x9c 0xce 0x6e 0x14 0xee 0xe2 0x57 0x74 0xb4 0x71 0x7e 0x8e 0x60 0xe3 0xe9 = 0x76 0x96 0x88 0x55 0x51 0x13 0xda 0x5e 0xfa 0xcf 0xc8 0x34 0xa3 0x6c 0xd5 0xbb = 0xbb 0xd8 0x3a 0x6f 0x9e 0x74 0x42 0xa8 0x46 0xed 0xde 0x2c 0x98 0x83 0x49 0xde= 0x25 0xa8 0x62 0x3a 0xa1 0x84 0x3e 0x00 0x7b 0x0d 0x3e 0x80 0x5f 0x49 0x20 0x6e = 0x08 For the actual use case, we have header information preceding the payload a= nd the header should remain unencrypted in the dst mbuf. Therefore, we stro= ngly believe that the second scenario is the desired behavior. There are ca= ses where we do need to execute cipher only (which we can do today via a NU= LL hash). To attest to that claim, we tested this scenario where we enable the authen= tication operation with everything else being the same: * symmetric operation * out-of-place operation * encryption * do cipher + do hash * cipher offset is non-zero * auth offset is zero The content in dst mbuf located in the cipher offset is copied over from sr= c mbuf for both src mbuf layout. Actual packet data: Src mbuf 0xcc 0x33, 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 = 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20= 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 = 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f 0x40 = 0x41 dst mbuf: Both in SGL, out SGL and in SGL, out SGL (both scenario 1 & 2) 0xcc 0x33 0x9c 0xce 0x6e 0x14 0xee 0xe2 0x57 0x74 0xb4 0x71 0x7e 0x8e 0x60 0xe3 0xe9 = 0x76 0x96 0x88 0x55 0x51 0x13 0xda 0x5e 0xfa 0xcf 0xc8 0x34 0xa3 0x6c 0xd5 0xbb = 0xbb 0xd8 0x3a 0x6f 0x9e 0x74 0x42 0xa8 0x46 0xed 0xde 0x2c 0x98 0x83 0x49 0xde= 0x25 0xa8 0x62 0x3a 0xa1 0x84 0x3e 0x00 0x7b 0x0d 0x3e 0x80 0x5f 0x49 0x20 0x6e = 0x08 0x50 0xa0 0x9f 0x15 Please let us know what your thoughts are about this issue and feel free to= contact us if there are any questions. Linfeng