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 57187A052B; Wed, 29 Jul 2020 18:19:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0D07AF04; Wed, 29 Jul 2020 18:19:01 +0200 (CEST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00046.outbound.protection.outlook.com [40.107.0.46]) by dpdk.org (Postfix) with ESMTP id C6BE02AB for ; Wed, 29 Jul 2020 18:18:59 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F4eWiTVTuvFlpOjN+pzU2Qcxfszi1s574JnM8QCZupoiEutgeBAP8WfSB1HdXMdzWzKyv0YrAp1T5KuFy7ax7QS2G7q2WewjPnCnuQkwWImVxQhFv+G1fqqCt+CSORNvac/CZWNRgav3wHLSqO31kXYKxtu71/R8p/+WoIU67Ccixm3VbvLxD4XcEYu46MwnhCvsNz+INstYRG8U6jGzRPwwt7ZXmvu40ga8zwpPAyFM7XlvKqdkHiVC+h45d6OQqnT6rUIncySGqZT3EhrrG4u6mC8i66T5VCe/Xr6LpuOwAEz9EOZh4ZvVd6EWTUOPWTeQYqIG0+M0l9FJV4dZhA== 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=kYC2kV7X6TC7M7IfY5PmYJlrxIO6Ji3SLLiMqamO+6U=; b=MJxyYuCs0bUrsiXmZa/BG9ycrZNBE+S7Ae7RK6opslXuADun/9sGWB4CR2SkkZT6okSJeGwnr9fUzZbHU81K3oW0xk3mObaONtFzKTH8Nisu5AJ3sJJOfZ+9lXKvPsuD/0y8NNC0tt0QSGGoGyw5MTNkDA79kXJXpR4qCtC8yBecXkySy0itQqD7ntoUon66RQY8rN1+u9Ilviys1x48swxkUNJPlKPODSNluPBcRGECgGbBW76FgiiwXX/6P/toVsZuzqL5KWrhKyptexRxKDHIOSkvsxYggUnIzDYR6xt9LOJAyCQQsfHqxt9Bm+Aeh5nqfczFv/VQlijuwYIhqA== 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=kYC2kV7X6TC7M7IfY5PmYJlrxIO6Ji3SLLiMqamO+6U=; b=oGG3bhizAsQOXfvGQdvUoCfcuv8XfJbozCoveA3Nv8UNFGj+0/8yjPaHuc6/PK1SDtclwpWEM5OlUjIHfRvjZ0gD6I1ajUNopzK1cXyxir1TVBnNOVSQlKHIoBsvhGXxWgp6nzBtqxxJPGKNSbZQoJBxQWnvkmeHrTIkYzZQMIM= Received: from VI1PR04MB3168.eurprd04.prod.outlook.com (10.170.227.10) by VI1PR04MB3005.eurprd04.prod.outlook.com (10.170.228.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16; Wed, 29 Jul 2020 16:18:58 +0000 Received: from VI1PR04MB3168.eurprd04.prod.outlook.com ([fe80::1c0f:eedb:1892:23fe]) by VI1PR04MB3168.eurprd04.prod.outlook.com ([fe80::1c0f:eedb:1892:23fe%3]) with mapi id 15.20.3239.017; Wed, 29 Jul 2020 16:18:58 +0000 From: Akhil Goyal To: Akhil Goyal , "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+sAIAKIhDggAFa4WA= Date: Wed, 29 Jul 2020 16:18:58 +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: nxp.com; dkim=none (message not signed) header.d=none;nxp.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [45.118.166.86] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a1fb3e58-180b-4241-9919-08d833db18e2 x-ms-traffictypediagnostic: VI1PR04MB3005: 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: r3DdNqiYPYjVvkTovoRSLpsdumuYfnvlSvQYj1liTfxlXZqU5HdwTFTbIY/3LxvO6Jbu48N+Xbzx5vIt3oc9pX6eNwOiy0h+48fFMqp9y15RNh8iBTE9MVr+Q6qD8BkehXfDxL21xTjhCvLyZZHROfs632C5wgvqkayVz9KeaJEk/sw3aLbqOM/3UJ6VT84m2ZG7Vjzx+kmunR8PT4T8WzDAiRMd7zNx7ySK/Ozid3E2m5i5C9Lh9CQB4fae6vIYhU4qac7IbftT2zZsFNZZJhogvgkd1lEw8r/wZ8Nlno6TOJEuIzRHBstqKVbhgHy2w05fDe0k2YRQrK2hv1lRxw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB3168.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(346002)(366004)(39860400002)(376002)(66476007)(66446008)(64756008)(66556008)(316002)(66946007)(110136005)(186003)(71200400001)(52536014)(26005)(6506007)(7696005)(54906003)(4326008)(76116006)(83380400001)(5660300002)(86362001)(2906002)(478600001)(55016002)(9686003)(44832011)(8936002)(8676002)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: UQV7tIt1gZLTvUVmHZkgPJtiOJsSnlXwbBZAz0813wkqJgwVws063jbFNPwuH4AmOnbzuTtzJLYTWYguQSX80Tajggq8MBoY9GCHqhw7uKi61jmlWcUCqSkDk55NThT8O4Sh1v6mJotU4EHpLttlmwDTaCtoRLfOfuMmIWLKtIERgj+EBiUsTSbXmLKYEr2I8qCTkLGofOAo/UWsZrcADp2Se3pt1PCINTBqG13VxOAQQcKvumaFQYG2nAmYPOQH9Yy7UVbWvnZZ0UWBDlJZ9lGTheVX3iWoySDrXtqPYRW3go4WhUm33CYG/1MhWjwim1pCLqh7LOk45h8xg6TxhaFlLLZL5shHDTLqgY4m2XXwB2edSPEFsX39PEI6X2gxVJKrH2v+8BCMknmE3J3wIu2H2X5I88cJS5rym1C0XuzIFhJpqG5LKTza0A2xuU8v2gke0nuxapUmcQpdEYkwBS9uk6VZXYhE93WxhGvmmOKcysA9R8oeqTo/lJBd/LR5XxbIsS6at1lZYKFLsQUHNJi7O5nHuDz06gPSux/HAm44oAa7mO+2R64T6lF2zrWo6hYDc4i0kuiXFLUHB+IuWUL5t0+7QekItKk/LctxiOl/AKW8eNe2d5Yz8/vLskuekvZV/XQYRY6GqyTqMiPl9A== 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: VI1PR04MB3168.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a1fb3e58-180b-4241-9919-08d833db18e2 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2020 16:18:58.0463 (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: dPCUboxcov6k3zTDqADYmFpOEzzzrUlN/grhFxcUVGXrRgZZsN+A77FR4R/wl0TGteIjxA87kRxSnJ+SaYvhTg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB3005 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, > > > > Hi David, > > > > > 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 > **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 pa= tch, > > right?). > > > > > > [DC] I have found that if a number of buffer sizes are specified like= this on > the > > > cmd line "--buffer-sz 64,256,1024", then the pkt_len and data_len fil= led in > > > "fill_multi_seg_mbuf" or " fill_single_seg_mbuf" is always the larges= t of the > > sizes > > > specified. The cipher/auth lengths are then set based on the --buffer= -sz > option. > > > > > > For DOCSIS, I tried to be more accurate and set the correct pkt_len a= nd > > data_len > > > in the mbuf. This followed what PDCP did too, even though I'm not sur= e 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 fo= r 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 = problem > > > across the perf tool. Some of the crypto PMDs have logic based on the= mbuf > > > pkt_len and data_len, but because the perf tool isn't always setting = these > fields > > > correctly, that logic may not work as expected. > > > > > > > > Right, thanks for checking this. If I remember correctly, it was fine t= o have this > > set to the maximum size as the important field for crypto PMDs to check= is the > > cipher/auth lengths, as you said. If there is more logic that depends o= n > data_len > > on other PMDs, I agree it might be a problem. The only usage I knew for= it was > > the multi segment case (in AES-GCM PMD), where data_len is checked in e= ach > > segment size to see if all the cipher/auth length resides within these = segments, > > but in the tool we set data_len for each segment when "going multi-segm= ent". > 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 function= s (for > > "normal" crypto). > > >=20 > In case of test-crypto-perf, the buffers are flat and there is no case of= multi > segment. > So this is not because of that. > In case of PDCP and probably all the protocol offload cases would need th= e > buf_len/ > data_len/pkt_len to be set properly. As the complete buffer is given to h= ardware > and depending on the headers added, HW/PMD will adjust these lengths when > the > packet is dequeued, provided it has room available to expand. >=20 > We may not need this in cases of pure crypto which have fixed lengths and= PMD > does > not control them. >=20 > So in my opinion this patch is fine. >=20 > Acked-by: Akhil Goyal >=20 >=20 This patch was applied yesterday to dpdk-next-crypto And is now pulled to master as well.