From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 614E09113 for ; Wed, 31 May 2017 09:48:55 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 May 2017 00:48:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,422,1491289200"; d="scan'208";a="1176420305" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by fmsmga002.fm.intel.com with ESMTP; 31 May 2017 00:48:54 -0700 Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by irsmsx105.ger.corp.intel.com (163.33.3.28) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 31 May 2017 08:48:53 +0100 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.133]) by irsmsx112.ger.corp.intel.com ([169.254.1.42]) with mapi id 14.03.0319.002; Wed, 31 May 2017 08:48:53 +0100 From: "De Lara Guarch, Pablo" To: "De Lara Guarch, Pablo" , "Doherty, Declan" , "Zhang, Roy Fan" CC: "dev@dpdk.org" , "Rybalchenko, Kirill" Thread-Topic: [dpdk-dev] [PATCH] crypto/scheduler: add multicore scheduling mode Thread-Index: AQHS1+5KujxBL1gZnk2/YOq7ECyXyKIOETzg Date: Wed, 31 May 2017 07:48:52 +0000 Message-ID: References: <1496002118-64735-1-git-send-email-pablo.de.lara.guarch@intel.com> In-Reply-To: <1496002118-64735-1-git-send-email-pablo.de.lara.guarch@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzRlYmRmYTktODg4Zi00ZjRkLWJkZjMtMmU2NzE3MTAwNGExIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkgxM3lOZG96eGR4WGVMYzZXYXJOcVh2TXJPVzlXNWxJVDk0WEszNVozNW89In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] crypto/scheduler: add multicore scheduling mode 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: , X-List-Received-Date: Wed, 31 May 2017 07:48:57 -0000 Hi Kirill, > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Pablo de Lara > Sent: Sunday, May 28, 2017 9:09 PM > To: Doherty, Declan; Zhang, Roy Fan > Cc: dev@dpdk.org; Rybalchenko, Kirill > Subject: [dpdk-dev] [PATCH] crypto/scheduler: add multicore scheduling > mode >=20 > From: Kirill Rybalchenko >=20 > Multi-core scheduling mode is a mode where scheduler distributes > crypto operations in a round-robin base, between several core > assigned as workers. >=20 > Signed-off-by: Kirill Rybalchenko > --- > app/test-crypto-perf/cperf_test_throughput.c | 2 + > drivers/crypto/scheduler/Makefile | 1 + > drivers/crypto/scheduler/rte_cryptodev_scheduler.c | 7 + > drivers/crypto/scheduler/rte_cryptodev_scheduler.h | 6 + > drivers/crypto/scheduler/scheduler_multicore.c | 405 > +++++++++++++++++++++ > drivers/crypto/scheduler/scheduler_pmd.c | 73 +++- > drivers/crypto/scheduler/scheduler_pmd_private.h | 4 + > lib/librte_cryptodev/rte_cryptodev.c | 2 +- > 8 files changed, 497 insertions(+), 3 deletions(-) > create mode 100644 drivers/crypto/scheduler/scheduler_multicore.c >=20 > diff --git a/app/test-crypto-perf/cperf_test_throughput.c b/app/test- > crypto-perf/cperf_test_throughput.c > index 61b27ea..0504a37 100644 > --- a/app/test-crypto-perf/cperf_test_throughput.c > +++ b/app/test-crypto-perf/cperf_test_throughput.c > @@ -502,6 +502,8 @@ cperf_throughput_test_runner(void *test_ctx) >=20 > } >=20 > + rte_cryptodev_stop(ctx->dev_id); This should be in a separate patch, but this is probably in the wrong place= , as this runner is called several times when using multiple buffer sizes. > + > return 0; > } >=20 ... > diff --git a/drivers/crypto/scheduler/scheduler_multicore.c > b/drivers/crypto/scheduler/scheduler_multicore.c > new file mode 100644 > index 0000000..12e5734 > --- /dev/null > +++ b/drivers/crypto/scheduler/scheduler_multicore.c > +struct mc_scheduler_qp_ctx { > + struct scheduler_slave > slaves[RTE_CRYPTODEV_SCHEDULER_MAX_NB_SLAVES]; > + uint32_t nb_slaves; > + > + uint32_t last_enq_worker_idx; > + uint32_t last_deq_worker_idx; I would say these can be uint8_t. ... > +static int > +scheduler_stop(struct rte_cryptodev *dev) > +{ > + struct scheduler_ctx *sched_ctx =3D dev->data->dev_private; > + struct mc_scheduler_ctx *mc_ctx =3D sched_ctx->private_ctx; > + > + mc_ctx->stop_signal =3D 1; > + for (uint16_t i =3D 0; i < sched_ctx->nb_wc; i++) Declare the variable "i" outside the foor loop. > + rte_eal_wait_lcore(sched_ctx->wc_pool[i]); > + > + return 0; > +} =20 > const struct scheduler_parse_map scheduler_ordering_map[] =3D { > @@ -117,6 +124,17 @@ cryptodev_scheduler_create(const char *name, > sched_ctx->max_nb_queue_pairs =3D > init_params->def_p.max_nb_queue_pairs; >=20 > + if (init_params->mode =3D=3D CDEV_SCHED_MODE_MULTICORE) { > + sched_ctx->nb_wc =3D 0; > + for (uint16_t i =3D 0; i < MAX_NB_WORKER_CORES; i++) { Declare variable "i" outside for loop. > + if (init_params->wcmask & (1ULL << i)) { > + sched_ctx->wc_pool[sched_ctx->nb_wc++] =3D > i; > + RTE_LOG(INFO, PMD, " Worker > core[%u]=3D%u added\n", > + sched_ctx->nb_wc-1, i); > + } > + } > + } > + > if (init_params->mode > CDEV_SCHED_MODE_USERDEFINED && > init_params->mode < CDEV_SCHED_MODE_COUNT) > { > ret =3D rte_cryptodev_scheduler_mode_set(dev->data- > >dev_id, > @@ -251,6 +269,42 @@ parse_integer_arg(const char *key __rte_unused, > return 0; > } >=20 ... > diff --git a/lib/librte_cryptodev/rte_cryptodev.c > b/lib/librte_cryptodev/rte_cryptodev.c > index b65cd9c..5aa2b8b 100644 > --- a/lib/librte_cryptodev/rte_cryptodev.c > +++ b/lib/librte_cryptodev/rte_cryptodev.c > @@ -1032,8 +1032,8 @@ rte_cryptodev_stop(uint8_t dev_id) > return; > } >=20 > - dev->data->dev_started =3D 0; > (*dev->dev_ops->dev_stop)(dev); > + dev->data->dev_started =3D 0; Separate patch for this. > } Last thing, there are some compilation issues to fix, according to patchwor= k: http://dpdk.org/ml/archives/test-report/2017-May/020993.html Thanks, Pablo