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 699D8A052B; Tue, 28 Jul 2020 21:44:17 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 473F91150; Tue, 28 Jul 2020 21:44:16 +0200 (CEST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80059.outbound.protection.outlook.com [40.107.8.59]) by dpdk.org (Postfix) with ESMTP id 5F8401023 for ; Tue, 28 Jul 2020 21:44:15 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ATgkK5ZzTxH1mcNTpcnH6kKZkzT1NBe0LjpqzzGQLxkyIEMdq4DdaAO7O8eYM0TwLXNpKJRTghV4/l/7EUlbQ3aibbimWqnAJQ0KDGJWb4TFEbC88FWbAaf/WDfCGuHdEX0jSiRqUu2V1DacJInhNtJr0ssW805rI60IJZmoNArQ5zc62M3nevbEgEIM4UAzIA3NCi1/uRW1tUwC1JgVgtLQMpC5fkpEts6nx5iQPzP1/nTN6ECZGcuelJhuYb6SvN52rF5PVdRA+7YgJ3aloWiR9F89rWApCJMRJiSm7rBuh2WW4FAJKm+pOj0SIGmG0GVKaj4jbDfFbB8VChh2tQ== 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=BfolmNLlYqleXKbFWXlu/3dBtImlr/nd6fvLZFJ4tvs=; b=jwaloEAS6/+BmhIBk0+cesq86urk4tDokTsE9MI0NZwFL45ud4yPU5XZjOlj9XzUKEi4UfykIqLmCcZnO+kZf+59QYjsYgB8lybrg/ShZhjNK22GPGNBoxaW6kzPSSbVjS3QQgvz4Khftm2eL90mLzTc/oVA8JzAr2ugmU4w7JC1eDPwHYRDDpiOkXidQF+sbadu+FOBTBS7JyLkLRm6YkxsCTh5k4472sXZfJxMXqfbSWoZgAXSH7YiFklIcBcba6FJH/dAIizyUk9IXVeJ4hRz4ggpZla6EHo+WfU4EOkLOKo8ecApQabH9+PBYaHnAh/B8ylgsRlkSRlJUqIMow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BfolmNLlYqleXKbFWXlu/3dBtImlr/nd6fvLZFJ4tvs=; b=GWdCRibxLi7SUvGAUMxKIXx9hbruUpYrciuBA00geM2n/e5h3VdksIy4uEvHbrm+iBrGBjzQQXaGcXwks7766opXh00bdy92n8SjsoncVATB/QNvERHx9iCqZhNQsXCifWbNLaFy7B+sBEnHlqQOAQihz8CcoEuVzDuv1xXXFXg= Received: from AM5PR04MB3153.eurprd04.prod.outlook.com (2603:10a6:206:e::26) by AM6PR0402MB3334.eurprd04.prod.outlook.com (2603:10a6:209:c::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.28; Tue, 28 Jul 2020 19:44:14 +0000 Received: from AM5PR04MB3153.eurprd04.prod.outlook.com ([fe80::9c5a:3faf:66e4:d8d3]) by AM5PR04MB3153.eurprd04.prod.outlook.com ([fe80::9c5a:3faf:66e4:d8d3%6]) with mapi id 15.20.3216.033; Tue, 28 Jul 2020 19:44:13 +0000 From: Akhil Goyal To: "De Lara Guarch, Pablo" , "Coyle, David" , "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: AQHWW4mDpmE2pOVvg02j00XKAt8F76kMIugAgARRG4CAAt+sAIAKIhDg Date: Tue, 28 Jul 2020 19:44:13 +0000 Message-ID: References: <20200716153111.65308-1-david.coyle@intel.com> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [45.118.166.90] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 756199df-a033-40fd-2d32-08d8332e9b40 x-ms-traffictypediagnostic: AM6PR0402MB3334: 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: gZhUTk0Et2eM3UXzU/Dx/u3wNP6VUdzUReN2+BaHMTFEiAFinzoxtOtmy1LyaN5+2Cn6w1sDOyp+K0v62oqxsKkQRGrO4+nP9gaFji6fXa6OzYL28M+h9Zk33pbgeLNPBI5blIZVrFqety9z/CARCuzof9/iJutcOk04zkkbQr5qbJH6eFf3+zUNQvdCFS6CfFZRmsYqk4ueEZ1sUgZpaEpAKRKU4uy5xnwtLvGf8ltmAk0np22FefEoac2bP7rigvPvR3kejzorwOMG+A7Xo+EG4SDnShGfIAjxF3x7GWWFCO3Vn6T0TjtVbg8GBFizOtPYIW+9WmnHMxr0auCGCA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM5PR04MB3153.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(110136005)(54906003)(4326008)(83380400001)(52536014)(498600001)(8936002)(86362001)(7696005)(33656002)(5660300002)(44832011)(9686003)(8676002)(186003)(64756008)(2906002)(66556008)(76116006)(66946007)(6506007)(71200400001)(26005)(66446008)(55016002)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: A6a7nQTPc16pdBXgMAp7X0bQSpLLIew8p/+vajJ+O20exqBFMDvIkqtY3t9nlPhsmqrIS875q+G0+rzFb9DjMaDwHLrv/gKvG+ZntQHoTO44G8BSzp5e9HTd01q2lB4AbBkq74pze8gwh1wT/JL2CG9xYGPNOACsjl3tjk8J0q4bS9HE1PzB0CROth2/dgTRxoK4QOQcbtTaOJ0kRKgeZ4+Au2G/fxerD8MFvm3w54tnLrk3JoSy978C3EqFt09br4BYxwsROSU7R92akopnWgMYM6GjXOT6QAprpy5jJn435A9lO4OLFOxvOjexD9oevur9b5VOYSJfljEImRINA0v3CkGrTUkjzQTqzx+D9HHu7t5tD7ELiDCBTAugepvRDd5NT2v7hzHgF/RuNm6P0EiXPvS85bvd8JSX4hx93gImiE9XYnYTirSBS5YC7pO+o8LQf0s3NwFj+vB0IM3eCY4jDluwWrUruFEzDJGoiCs= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM5PR04MB3153.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 756199df-a033-40fd-2d32-08d8332e9b40 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 19:44:13.8622 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mCvHDAv7ViqJ5gde0icvAhPYHKz2nzyLIt7eg1AJbwcFgeZC/NHgReRhLWopM8sCXcw6Dm6DHRXSZwaKlynAVw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0402MB3334 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 Pablo/David, >=20 > Hi David, >=20 > > Hi Pablo, > > > > > -----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 **op= s, > > > > } 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 patc= h, > right?). > > > > [DC] I have found that if a number of buffer sizes are specified like t= his on the > > cmd line "--buffer-sz 64,256,1024", then the pkt_len and data_len fille= d 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-s= z option. > > > > For DOCSIS, I tried to be more accurate and set the correct pkt_len and > data_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 al= so > found > > that DOCSIS performance figures can be better if the correct pkt_len an= d > > data_len are set in the mbuf - I don't have any proper explanation for = this > > though as the cipher/ auth lengths are always the same. > > > > I've dug around a bit more on this now though and this is actually a pr= oblem > > across the perf tool. Some of the crypto PMDs have logic based on the m= buf > > pkt_len and data_len, but because the perf tool isn't always setting th= ese fields > > correctly, that logic may not work as expected. > > > > > Right, thanks for checking this. If I remember correctly, it was fine to = have this > set to the maximum size as the important field for crypto PMDs to check i= s the > cipher/auth lengths, as you said. If there is more logic that depends on = data_len > on other PMDs, I agree it might be a problem. The only usage I knew for i= t was > the multi segment case (in AES-GCM PMD), where data_len is checked in eac= h > segment size to see if all the cipher/auth length resides within these se= gments, > but in the tool we set data_len for each segment when "going multi-segmen= t". I > see that other PMDs like DPAA2_SEC use these 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, this should be fixed for the other functions = (for > "normal" crypto). >=20 In case of test-crypto-perf, the buffers are flat and there is no case of m= ulti segment. So this is not because of that. In case of PDCP and probably all the protocol offload cases would need the = buf_len/ data_len/pkt_len to be set properly. As the complete buffer is given to har= dware and depending on the headers added, HW/PMD will adjust these lengths when t= he packet is dequeued, provided it has room available to expand. We may not need this in cases of pure crypto which have fixed lengths and P= MD does not control them. So in my opinion this patch is fine. Acked-by: Akhil Goyal