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 A3102FAC7 for ; Wed, 29 Mar 2017 22:10:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1490818217; x=1522354217; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GUlvOIHLe3D7QvA7YygTRpB9l8pGzns+EgUAkgtzocc=; b=V3BklHMdgUW8mHci6hv8x38XmXtYShpUMXkuY9U5pImKrn8q0suLX29J hzCJSR8T0WqJ1O7AalxI0GCuCs3pIA==; Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Mar 2017 13:09:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,242,1486454400"; d="scan'208";a="82434332" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by fmsmga006.fm.intel.com with ESMTP; 29 Mar 2017 13:09:53 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.239]) by IRSMSX154.ger.corp.intel.com ([169.254.12.233]) with mapi id 14.03.0319.002; Wed, 29 Mar 2017 21:09:46 +0100 From: "De Lara Guarch, Pablo" To: "Zhang, Roy Fan" , "dev@dpdk.org" CC: "Gonzalez Monroy, Sergio" , "Doherty, Declan" Thread-Topic: [PATCH v5 1/3] crypto/scheduler: add packet size based mode code Thread-Index: AQHSqKj+cFs/RqgMq0GsuKhdQs/whKGsPNRQ Date: Wed, 29 Mar 2017 20:09:45 +0000 Message-ID: References: <1490775959-65295-1-git-send-email-roy.fan.zhang@intel.com> <1490804784-64350-1-git-send-email-roy.fan.zhang@intel.com> <1490804784-64350-2-git-send-email-roy.fan.zhang@intel.com> In-Reply-To: <1490804784-64350-2-git-send-email-roy.fan.zhang@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGZhNzIxMzctNjBkNS00ZGVlLWI1MDAtMGY0MzM3NGRhZTEwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Im1iZmNwOHEzWlNmbHhpaDlKRzRlZFBydStrOTUxRnU4blVUQTgxYm9pSWc9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v5 1/3] crypto/scheduler: add packet size based mode code 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, 29 Mar 2017 20:10:18 -0000 Hi Fan, > -----Original Message----- > From: Zhang, Roy Fan > Sent: Wednesday, March 29, 2017 5:26 PM > To: dev@dpdk.org > Cc: De Lara Guarch, Pablo; Gonzalez Monroy, Sergio; Doherty, Declan > Subject: [PATCH v5 1/3] crypto/scheduler: add packet size based mode > code >=20 > This patch adds the packet size based distribution mode main source > file. >=20 > Packet-size based distribution mode is a scheduling mode works with 2 > slaves, primary slave and secondary slave, and distribute the enqueued > crypto ops to them based on their data lengths. A crypto op will be > distributed to the primary slave if its data length equals or bigger > than the designated threshold, otherwise it will be handled by the > secondary slave. >=20 > Signed-off-by: Fan Zhang > Series-acked-by: Pablo de Lara I haven't acked this patch yet :P. Actually, I have one comment below. > --- > .../crypto/scheduler/scheduler_pkt_size_distr.c | 410 > +++++++++++++++++++++ > 1 file changed, 410 insertions(+) > create mode 100644 drivers/crypto/scheduler/scheduler_pkt_size_distr.c >=20 > diff --git a/drivers/crypto/scheduler/scheduler_pkt_size_distr.c > b/drivers/crypto/scheduler/scheduler_pkt_size_distr.c > new file mode 100644 > index 0000000..8da10c8 > --- /dev/null > +++ b/drivers/crypto/scheduler/scheduler_pkt_size_distr.c ... > +static uint16_t > +schedule_enqueue(void *qp, struct rte_crypto_op **ops, uint16_t > nb_ops) > +{ ... > + job_len =3D ops[i]->sym->cipher.data.length; > + job_len +=3D (ops[i]->sym->cipher.data.length =3D=3D 0) * > + ops[i]->sym->auth.data.length; > + /* decide the target op based on the job length */ > + p_enq_op =3D &enq_ops[!(job_len & qp_ctx->threshold)]; > + sched_ops[p_enq_op->slave_idx][p_enq_op->pos] =3D ops[i]; > + ops[i]->sym->session =3D sess->sessions[p_enq_op- > >slave_idx]; > + p_enq_op->pos++; > + > + /* stop schedule cops before the queue is full, this shall > + * prevent the failed enqueue > + */ > + if (p_enq_op->pos + in_flight_ops[p_enq_op->slave_idx] >=3D > + qp_ctx->max_nb_objs) { > + i =3D nb_ops; > + break; > + } If (in_flight_ops =3D=3D qp_ctx->max_nb_objs), then you won't even be able = to enqueue a single crypto operation (as the device is completely full), but at this s= tage,=20 you have already modified the session of the operation, so you need to avoi= d this situation. Thanks, Pablo