From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id A1231A0526; Wed, 22 Jul 2020 10:52:17 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 35CBF1BFD4; Wed, 22 Jul 2020 10:52:16 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 04A6B1BFD1 for ; Wed, 22 Jul 2020 10:52:13 +0200 (CEST) IronPort-SDR: 0F6KVo8vdiFAZ64SyP0qTmfaTjmInb/33fSGj7yMg2/P1ePAjelaMudYcNcggSTF8uI26G0ZDR HN3R0iZx8F7Q== X-IronPort-AV: E=McAfee;i="6000,8403,9689"; a="151619025" X-IronPort-AV: E=Sophos;i="5.75,381,1589266800"; d="scan'208";a="151619025" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jul 2020 01:52:12 -0700 IronPort-SDR: 6+VW6NZZw0PyhD0k3XfZDO3D1upGALmUFZ1HLuNl/S6O4Kj8uzm+sowWdhATpkR3oSzwSlIrKt G+3BurUqIUPQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,381,1589266800"; d="scan'208";a="462383477" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga005.jf.intel.com with ESMTP; 22 Jul 2020 01:52:12 -0700 Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 22 Jul 2020 01:52:11 -0700 Received: from FMSEDG001.ED.cps.intel.com (10.1.192.133) by fmsmsx156.amr.corp.intel.com (10.18.116.74) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 22 Jul 2020 01:52:11 -0700 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.106) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 22 Jul 2020 01:52:11 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JnG+LefMhOkdZCW1ATF+clkvP9Qz5aS8oi6BL+kaQWIifNI31uQIuiN//TSY5hpVaqSvlF950xibJ1rk+Es20x4i4yYE+xQt/SBxTSHi5Zl7DHmdRn5gQXhOAl27tdYTPth5yCiY2oJaNmhOKjyq0qgIoNjkihL/RVfVraH/pSBoanZv6f0UHExElZzoue5dQ4Vmo7/rukn5aBQzt/i8+u199NcTruEuXAJdEEJYVDZOCVQY4zHYAbz0XGPO268dLOVegwTN3y9MOzsyNgvmlXBTaolZqw+7iDHYfLg3pCU8jOPcs/2QdzKnw2RgTXLxZWhsDajNnR4ds2wcvFHoCA== 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=n5t8X+w2IuWq3Obuu+9zhzq6L0KztvNI6t46W6t/Eug=; b=ECddOVeYy3GTcmAEuNiMx5jzl15byIgKhrt7I7P3ZzVrS0dI2VIerluPcGqE0kv3VqE95R2GiOP1uGHWVZ3L6Whoyjd1JP50oqAAhejtjklS3RcCMjVxXB8GDKpshTXZheA225BSnUkAga5U11toJ4RWMcle8FQs2/dS8WwemP5e2DXdjgHHyF9U1IezMSvVqQNBK5bnQqdCU3uJAxtF9k5duAO0TMXOIcGq4jx+N1oUKy06AKzEpKcd30Jvq4zecoAYFn27ROPBtyHT08O47ncTh0r+Q7K9Bb5QcNvk0YFOXkTufp9XOgh8SaYf/B1gA6K3No8iPT5YMM+/ytwE4Q== 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=n5t8X+w2IuWq3Obuu+9zhzq6L0KztvNI6t46W6t/Eug=; b=qXi78OtHBJeWybNQ+LJHzzniv1B/1BuCSv4syoELERMd5mSBUNn/cyth06OwSRY1oY8DgZ7lzYfyS8ZxtYklZ1fIZvzT2KA85upFkbN5cUKtO0tqXrUYLM2qVXUPPAwMlcNebB1vLQVYCDvBKQemb7VDzF+B2O84gcARvXkOaQg= Received: from SN6PR11MB3101.namprd11.prod.outlook.com (2603:10b6:805:d8::23) by SN6PR11MB3151.namprd11.prod.outlook.com (2603:10b6:805:d2::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.22; Wed, 22 Jul 2020 08:52:08 +0000 Received: from SN6PR11MB3101.namprd11.prod.outlook.com ([fe80::ac58:2cf3:c611:9b0]) by SN6PR11MB3101.namprd11.prod.outlook.com ([fe80::ac58:2cf3:c611:9b0%3]) with mapi id 15.20.3195.027; Wed, 22 Jul 2020 08:52:08 +0000 From: "De Lara Guarch, Pablo" To: "Coyle, David" , "akhil.goyal@nxp.com" , "Doherty, Declan" , "Trahe, Fiona" CC: "dev@dpdk.org" , "Ryan, Brendan" , "O'loingsigh, Mairtin" Thread-Topic: [PATCH v1] app/crypto-perf: set mbuf lengths correctly for DOCSIS tests Thread-Index: AQHWW4mJlNwB4oRc70ioQOhVDc+toqkMIfDggARSE4CAAtxBMA== Date: Wed, 22 Jul 2020 08:52:08 +0000 Message-ID: References: <20200716153111.65308-1-david.coyle@intel.com> 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.2.0.6 authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [109.255.188.24] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cb066035-1f1a-4854-9a7a-08d82e1c8469 x-ms-traffictypediagnostic: SN6PR11MB3151: 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: e+GY3daE1EQWX2NSiGczCU6KJe1u/4ZzoZ38KVOiFE7MXSg8ojnMvvSUHwTNfvXuh/kAenhYzYH+OtGV1UKB7tpWxb+h2TGSVxODfkdrxRjEvzRascLh0cToBZRVaw01+3lTTF7LXGsTo9oMbU57cYID7R/2BLrNofltxeHcicSoNFH3OvPMkvGLb74CjU51midA2+6xtUgUwKcJRc/GM9BXcIiZ2pKFX5vUEzJMlbsOa0DtPsqG2kMvXspAoxkpFnEyyILZrtvCETsviL4lmBveewb+xqNsaRw+uq2U18kFswoffGWgcxZQCkBfBG5j7uNo7bmxL2UQnzwzJ0WoNw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR11MB3101.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(396003)(346002)(136003)(366004)(6636002)(71200400001)(86362001)(6506007)(53546011)(66946007)(76116006)(7696005)(186003)(52536014)(8936002)(83380400001)(9686003)(55016002)(26005)(107886003)(4326008)(8676002)(2906002)(54906003)(110136005)(33656002)(316002)(478600001)(5660300002)(66476007)(66556008)(64756008)(55236004)(66446008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: TDuVSOHGoDwt4xyvUncNEULDf/9+w9DSXhPis/WVpQYtRH3HpTXooCw7GHVZ86nHHIdHeTiO2ynQzFDk5eWsVXJFPqH5Gkde3SfJXwrhbrZH3cU4s6GCDyP6+sYeaQlt3la+kMIbFTHehmEANxYskK4v0PBExes2Blus+cDXJTTDbOG2TvYY0V/vX51964uASpV6CGFr+bSBtfTWY82aQE7jbUYVGBGB3AflZfZr/xr3dRBCCP8VO+bWSRuoxhfJnwYfwGrelP4TMaFh4fFPf58PBNUPPmdEhHVvFINQDmg66hjg8rA/fURnQOdw+pVLG64hTVUAOyxE4cu7kYh+XGYQMydkcZf7HhfWcjkTttYNUVKKTfxAvIrQmQ8Xv+ICEvH2oM9BxOtfxmRo8Y2B4Ic/GyqXJamcZI54ddra7ICVw3e2ZS82B2LFK9LTfKvPCKoEE+l5VW72xBd2u/8Pctpi6sH8Doi4Qu4VOvRl9qpG1brXpuzhXzMMYG+zoYkk Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR11MB3101.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cb066035-1f1a-4854-9a7a-08d82e1c8469 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 08:52:08.6481 (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: kQteUaqxvrBvhkfTgpFk8aNp5ZwbcmkhRUqfa00+ZNibGamgNx6tcvYFvqXc3QhtGoEbg/9KQMbaYYDbGqLRsLovvLg3zJTyuUgQcqtvApc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3151 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v1] app/crypto-perf: set mbuf lengths correctly for DOCSIS tests 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" Hi David, > -----Original Message----- > From: Coyle, David > Sent: Monday, July 20, 2020 1:59 PM > To: De Lara Guarch, Pablo ; > akhil.goyal@nxp.com; Doherty, Declan ; Trahe, > Fiona > Cc: dev@dpdk.org; Ryan, Brendan ; O'loingsigh, > Mairtin > Subject: RE: [PATCH v1] app/crypto-perf: set mbuf lengths correctly for D= OCSIS > tests >=20 > Hi Pablo, >=20 > > -----Original Message----- > > From: De Lara Guarch, Pablo > > Sent: Friday, July 17, 2020 8:04 PM > > > @@ -48,6 +48,10 @@ cperf_set_ops_security(struct rte_crypto_op **ops, > > > } else > > > buf_sz =3D options->test_buffer_size; > > > > > > + sym_op->m_src->buf_len =3D options->segment_sz; > > > + sym_op->m_src->data_len =3D buf_sz; > > > + sym_op->m_src->pkt_len =3D buf_sz; > > > + > > > > Actually, I am wondering why this is needed at all (for DOCSIS and > > PDCP). This is already set in " fill_multi_seg_mbuf" or " > > fill_single_seg_mbuf" (and this was already working without this patch,= right?). >=20 > [DC] I have found that if a number of buffer sizes are specified like thi= s on the > cmd line "--buffer-sz 64,256,1024", then the pkt_len and data_len filled = in > "fill_multi_seg_mbuf" or " fill_single_seg_mbuf" is always the largest of= the sizes > specified. The cipher/auth lengths are then set based on the --buffer-sz = option. >=20 > For DOCSIS, I tried to be more accurate and set the correct pkt_len and d= ata_len > in the mbuf. This followed what PDCP did too, even though I'm not sure of= the > background why PDCP did it - possibly spotted the same issue. I have also= found > that DOCSIS performance figures can be better if the correct pkt_len and > data_len are set in the mbuf - I don't have any proper explanation for th= is > though as the cipher/ auth lengths are always the same. >=20 > I've dug around a bit more on this now though and this is actually a prob= lem > across the perf tool. Some of the crypto PMDs have logic based on the mbu= f > pkt_len and data_len, but because the perf tool isn't always setting thes= e fields > correctly, that logic may not work as expected. > > Right, thanks for checking this. If I remember correctly, it was fine to ha= ve this set to the maximum size as the important field for crypto PMDs to c= heck is the cipher/auth lengths, as you said. If there is more logic that d= epends on data_len on other PMDs, I agree it might be a problem. The only u= sage I knew for it was the multi segment case (in AES-GCM PMD), where data_= len is checked in each segment size to see if all the cipher/auth length re= sides within these segments, but in the tool we set data_len for each segme= nt when "going multi-segment". I see that other PMDs like DPAA2_SEC use the= se fields for something which I am not sure what's for. It would be good if= the maintainers check if this is a problem for them, and in that case, thi= s should be fixed for the other functions (for "normal" crypto). Thanks, Pablo