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 73A54A0524; Fri, 31 Jan 2020 17:32:11 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 44AB31C0D5; Fri, 31 Jan 2020 17:32:10 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 1922F1C0D0 for ; Fri, 31 Jan 2020 17:32:08 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2020 08:32:07 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,386,1574150400"; d="scan'208";a="224486430" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by fmsmga008.fm.intel.com with ESMTP; 31 Jan 2020 08:32:07 -0800 Received: from ORSEDG001.ED.cps.intel.com (10.7.248.4) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 31 Jan 2020 08:32:06 -0800 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.45) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 31 Jan 2020 08:32:06 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H2vq4dPdMMOoOeVoBUwcVr8u89BznoNL9UmVyikJ6K2mswEEWIAd1GOoKyddU6h697EtV0Hh9WOpvqOAzzOgqU4zWNqqRVmk019Gk4evMps8LOLJXlEDpUuMOvACWwu/hc5oJfReNSZfXCXCMzG1Ip1XGgVqrKnxEQkxZT0lgFecBJrjO+KRna/O77sCwAberJSuIHeNWH6LJMPpnMnmiXBLDEuuIXE2Nvwleut6Tf4Vw6epponybmFZUDh7ZwaCJVNQQxDFuyOyTyTnrsA18dCTpBUVckWwHJm2bIF4WLBN2RGLocLXe8YgbGbiI+ATXj0UC1H5xChWA1ZfpkmCXg== 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=hYiKTdB06yFRmbhsKkNcAsDdLKp03pFqeFWNDcrHl6I=; b=dgYulRGbU+yWk8wuWZzRg4fShweH1Uj5IhwTMPZwFWM8IYPY3O4kwsolQoLgH6xtPKcieP05U+D6ySIOZi8+J3YjDfKDpv25TvXSh90OtPag+bB26WHGjmm7v2lgoymlCVJEq7O8e+IvYoJ19FDmThpiUIa2ER+Ub8brMfOEp6cdixYYsYxt9BbD/OYjoeiiy161EJ3IGXdHkUm0lDh9ojjom5iK6AUCisTukY0GH7Uj13JdFWHugBg/m3XEa5POpEhkuf/toFD5jLwo15vi7WA4bbMlB0pKNei0VqB0F6laJ80x1FnQbSZA7Pek1JP4bNcpn7Dyf2pcV72Dux8TpA== 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=hYiKTdB06yFRmbhsKkNcAsDdLKp03pFqeFWNDcrHl6I=; b=nNChucuOoBRijPuCrG5EqLGBi7aSSiljjbZSm6f3GnhwD/bdGwufsA9bNUocYfZxngxwh4aTKf4bugSZ8K5WzXUQT/EoWngS8G9Ibt6Cy7A3PfOEOsBB2DJkQ0WJOQhWBRoZJehRzo7yhpx3Rg5I3/ZMWGJZMTjNoCMRlaT05QU= Received: from SN6PR11MB2558.namprd11.prod.outlook.com (52.135.94.19) by SN6PR11MB3502.namprd11.prod.outlook.com (52.135.127.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.22; Fri, 31 Jan 2020 16:32:05 +0000 Received: from SN6PR11MB2558.namprd11.prod.outlook.com ([fe80::4d86:362a:13c3:8386]) by SN6PR11MB2558.namprd11.prod.outlook.com ([fe80::4d86:362a:13c3:8386%7]) with mapi id 15.20.2665.027; Fri, 31 Jan 2020 16:32:05 +0000 From: "Ananyev, Konstantin" To: Anoob Joseph , Akhil Goyal , "Nicolau, Radu" CC: Jerin Jacob Kollanukkaran , Lukas Bartosik , Narayana Prasad Raju Athreya , "dev@dpdk.org" Thread-Topic: [PATCH] examples/ipsec-secgw: increase number of qps to lcore_params Thread-Index: AQHVx8T0p6tfWl36AEO+n9Pp5WnH2agCUR9ggAEz9gCAAYtkUA== Date: Fri, 31 Jan 2020 16:32:04 +0000 Message-ID: References: <1578667598-18942-1-git-send-email-anoobj@marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMDc1ZDc0YzQtMzAwNy00YjNhLWE3ZGEtMjU0YmUzZjA2YzM3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoicVlxeU9CRzBMSVc3SWppaDNpeFh2TTdPaU8yVitWYnkyRU9uNk1aR09MWHNRYUh5YXpWUWpkZ3FseGpSam9oSCJ9 dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 x-ctpclassification: CTP_NT authentication-results: spf=none (sender IP is ) smtp.mailfrom=konstantin.ananyev@intel.com; x-originating-ip: [46.7.38.224] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ea4a6484-6888-4b7d-1ebb-08d7a66b1b95 x-ms-traffictypediagnostic: SN6PR11MB3502: 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:3826; x-forefront-prvs: 029976C540 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(396003)(346002)(376002)(136003)(199004)(189003)(86362001)(33656002)(8936002)(81156014)(81166006)(64756008)(66476007)(6506007)(8676002)(66556008)(66446008)(7696005)(6636002)(76116006)(66946007)(186003)(26005)(71200400001)(9686003)(478600001)(2906002)(55016002)(4326008)(110136005)(316002)(52536014)(5660300002)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR11MB3502; H:SN6PR11MB2558.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IFxSbqAkDypTRMbDKsdnPM6SJbbSo59Opd3fQTwGpUdbVZVHJWFIDDqa0b3iyJiwSWzToIxuNNAvhYXqon97ygNc7q4ZrLGDtYZixbA2yyRdni3YCIqs45jht5aIm9BVamBw1hNoULMnccmZgS5RW7BAR6KtX+OvqDZL2kKvu07m0W5bZ7efzebu1d0l1nwiRXl6M6b2qcFx4p5dQpZQNDNnuqa/3Uj4qtdfhLa6lTSwSITHzXb3Td/UMDuE1d0EEXGL9VNpvSqVAbphFBO/gLWhYDj5Y9hD0q/PHn90SILNVdNyxG9Mo88zZSpF0ogfgzGH1m2WMZAgOZV+9ToeAhyTPIITuxztSGEpdIgpyKUIK1yUjs67pPJot3rBeFP0GF60ts52KfI72ATqNMLY17gSXkKnE8UzOeh4v+lp+T2toQx8pIKS3KWvTIUAG/W/ x-ms-exchange-antispam-messagedata: AMujgrZjm3U+H7+UX32m/ZDgZrVTy1t6Tz6jsksTEZcd/EjwhwHLMdvvmhj7QNEKNaOtN8sfcMydJNF4xc0FIqb0viRqobB9axGMJqpa0nzd1OBPH2tqakoLpsJmFn1HKPoojRXMngSZ3nWfg4LccQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ea4a6484-6888-4b7d-1ebb-08d7a66b1b95 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2020 16:32:04.7795 (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: x39tY7eiLyh09J97jOGMb9nNl/DXOl7xebnYPTxjejAOIH5JwoYKd9XhNVhuATJfNQAR0/oCQsXJzPu4wHC+MmX2sOHvNDQSHe8HdCI/hMU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3502 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH] examples/ipsec-secgw: increase number of qps to lcore_params 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" > > > > ---------------------------------------------------------------------- > > > > > > > > > > Currently only one qp will be used for one core. The number of qps ca= n > > > be increased to match the number of lcore params. > > > > I don't really understand the purpose of that patch.... > > As I understand, all it does - unconditionally increases number of cryp= to-queues > > mapped to the same lcore. >=20 > [Anoob] With the current code, we will have only crypto qp mapped to one = lcore. So even if you have large number of crypto qps, you > would be only using as much as the number of lcores. >=20 > This is an inefficient model as a fat flow(say with large packet sizes) o= n one eth queue hitting one core can starve another flow which > happens to hit the same core, because both flows would get queued to the = same qp. > And, we cannot just randomly submit to multiple qps > from the same core as then the ordering would be messed up.=20 No-one suggesting that one I believe. So the best possible usage model would be to map one eth queue to one > crypto qp. That way, the core wouldn't be unnecessarily pipeline the cryp= to processing. I doubt it is really the 'best possible usage model'. There could be cases when forcing lcore to use/manage more crypto-queues wi= ll lead to negative effects: perf drop, not enough crypto queues for all eth queues, e= tc. If your HW/SW requires to match each eth queue with a separate crypto-queue= , then I think it should be an optional feature, while keeping default behavi= or intact. =20 >=20 > > The question is what for? > > All these extra queues woulnd't be used by current poll mode data-path = anyway. > > Plus in some cases hash_lookup() would fail to find existing mapping. >=20 > [Anoob] It was an issue with v1 that we have addressed with v2. I'll send= v2 shortly. Please do check that see if you have more comments. >=20 > > I understand that for your eventdev implementation you need one crypto = queue > > for each eth device. > > But I think it could be done in less intrusive way (see my previous mai= l as one > > possible option). >=20 > [Anoob] If this suggestion is agreeable, then we can solve both qp number= requirement (for inline) and default nb_mbuf calculation in a > much more sensible way. If this doesn't fly, I'll probably go back to you= r suggestion, but then there would be more code just to handle these > cases. And the nb_mbuf calculation could turn slightly complicated. Don't see how it affects number of required mbufs... Wouldn't it just be: * + = * + *+.... ? =20 >=20 > > Konstantin > > > > > > > > Signed-off-by: Anoob Joseph > > > --- > > > examples/ipsec-secgw/ipsec-secgw.c | 39 +++++++++++++++++++---------= ----- > > ----- > > > examples/ipsec-secgw/ipsec.h | 4 +++- > > > 2 files changed, 23 insertions(+), 20 deletions(-) > > > > > > diff --git a/examples/ipsec-secgw/ipsec-secgw.c > > > b/examples/ipsec-secgw/ipsec-secgw.c > > > index 3b5aaf6..d8c435e 100644 > > > --- a/examples/ipsec-secgw/ipsec-secgw.c > > > +++ b/examples/ipsec-secgw/ipsec-secgw.c > > > @@ -1709,6 +1709,8 @@ add_mapping(struct rte_hash *map, const char > > *str, uint16_t cdev_id, > > > unsigned long i; > > > struct cdev_key key =3D { 0 }; > > > > > > + key.port_id =3D params->port_id; > > > + key.queue_id =3D params->queue_id; > > > key.lcore_id =3D params->lcore_id; > > > if (cipher) > > > key.cipher_algo =3D cipher->sym.cipher.algo; @@ -1721,23 > > +1723,17 @@ > > > add_mapping(struct rte_hash *map, const char *str, uint16_t cdev_id, > > > if (ret !=3D -ENOENT) > > > return 0; > > > > > > - for (i =3D 0; i < ipsec_ctx->nb_qps; i++) > > > - if (ipsec_ctx->tbl[i].id =3D=3D cdev_id) > > > - break; > > > - > > > - if (i =3D=3D ipsec_ctx->nb_qps) { > > > - if (ipsec_ctx->nb_qps =3D=3D MAX_QP_PER_LCORE) { > > > - printf("Maximum number of crypto devices assigned to > > " > > > - "a core, increase MAX_QP_PER_LCORE > > value\n"); > > > - return 0; > > > - } > > > - ipsec_ctx->tbl[i].id =3D cdev_id; > > > - ipsec_ctx->tbl[i].qp =3D qp; > > > - ipsec_ctx->nb_qps++; > > > - printf("%s cdev mapping: lcore %u using cdev %u qp %u " > > > - "(cdev_id_qp %lu)\n", str, key.lcore_id, > > > - cdev_id, qp, i); > > > + i =3D ipsec_ctx->nb_qps; > > > + if (ipsec_ctx->nb_qps =3D=3D MAX_QP_PER_LCORE) { > > > + printf("Maximum number of crypto devices assigned to a core, " > > > + "increase MAX_QP_PER_LCORE value\n"); > > > + return 0; > > > } > > > + ipsec_ctx->tbl[i].id =3D cdev_id; > > > + ipsec_ctx->tbl[i].qp =3D qp; > > > + ipsec_ctx->nb_qps++; > > > + printf("%s cdev mapping: lcore %u using cdev %u qp %u " > > > + "(cdev_id_qp %lu)\n", str, key.lcore_id, cdev_id, qp, i); > > > > > > ret =3D rte_hash_add_key_data(map, &key, (void *)i); > > > if (ret < 0) { > > > @@ -1785,8 +1781,10 @@ add_cdev_mapping(struct rte_cryptodev_info > > *dev_info, uint16_t cdev_id, > > > continue; > > > > > > if (i->sym.xform_type =3D=3D RTE_CRYPTO_SYM_XFORM_AEAD) { > > > - ret |=3D add_mapping(map, str, cdev_id, qp, params, > > > + ret =3D add_mapping(map, str, cdev_id, qp, params, > > > ipsec_ctx, NULL, NULL, i); > > > + if (ret) > > > + return ret; > > > continue; > > > } > > > > > > @@ -1801,12 +1799,15 @@ add_cdev_mapping(struct rte_cryptodev_info > > *dev_info, uint16_t cdev_id, > > > if (j->sym.xform_type !=3D > > RTE_CRYPTO_SYM_XFORM_AUTH) > > > continue; > > > > > > - ret |=3D add_mapping(map, str, cdev_id, qp, params, > > > + ret =3D add_mapping(map, str, cdev_id, qp, params, > > > ipsec_ctx, i, j, NULL); > > > + if (ret) > > > + return ret; > > > + continue; > > > } > > > } > > > > > > - return ret; > > > + return 0; > > > } > > > > > > /* Check if the device is enabled by cryptodev_mask */ diff --git > > > a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h index > > > 8e07521..92fd5eb 100644 > > > --- a/examples/ipsec-secgw/ipsec.h > > > +++ b/examples/ipsec-secgw/ipsec.h > > > @@ -200,7 +200,9 @@ struct ipsec_ctx { }; > > > > > > struct cdev_key { > > > - uint16_t lcore_id; > > > + uint16_t port_id; > > > + uint8_t queue_id; > > > + uint8_t lcore_id; > > > uint8_t cipher_algo; > > > uint8_t auth_algo; > > > uint8_t aead_algo; > > > -- > > > 2.7.4