From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id E66B55598 for ; Fri, 2 Dec 2016 15:57:36 +0100 (CET) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga102.jf.intel.com with ESMTP; 02 Dec 2016 06:57:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,287,1477983600"; d="scan'208";a="36507920" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.64]) by orsmga004.jf.intel.com with SMTP; 02 Dec 2016 06:57:32 -0800 Received: by (sSMTP sendmail emulation); Fri, 02 Dec 2016 14:57:31 +0000 Date: Fri, 2 Dec 2016 14:57:31 +0000 From: Bruce Richardson To: Thomas Monjalon Cc: Fan Zhang , dev@dpdk.org, declan.doherty@intel.com Message-ID: <20161202145730.GA322432@bricha3-MOBL3.ger.corp.intel.com> References: <1480688123-39494-1-git-send-email-roy.fan.zhang@intel.com> <8047937.9v81RFizFU@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8047937.9v81RFizFU@xps13> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.7.1 (2016-10-04) Subject: Re: [dpdk-dev] [PATCH] Scheduler: add driver for scheduler crypto pmd 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: Fri, 02 Dec 2016 14:57:37 -0000 On Fri, Dec 02, 2016 at 03:31:24PM +0100, Thomas Monjalon wrote: > 2016-12-02 14:15, Fan Zhang: > > This patch provides the initial implementation of the scheduler poll mode > > driver using DPDK cryptodev framework. > > > > Scheduler PMD is used to schedule and enqueue the crypto ops to the > > hardware and/or software crypto devices attached to it (slaves). The > > dequeue operation from the slave(s), and the possible dequeued crypto op > > reordering, are then carried out by the scheduler. > > > > The scheduler PMD can be used to fill the throughput gap between the > > physical core and the existing cryptodevs to increase the overall > > performance. For example, if a physical core has higher crypto op > > processing rate than a cryptodev, the scheduler PMD can be introduced to > > attach more than one cryptodevs. > > > > This initial implementation is limited to supporting the following > > scheduling modes: > > > > - CRYPTO_SCHED_SW_ROUND_ROBIN_MODE (round robin amongst attached software > > slave cryptodevs, to set this mode, the scheduler should have been > > attached 1 or more software cryptodevs. > > > > - CRYPTO_SCHED_HW_ROUND_ROBIN_MODE (round robin amongst attached hardware > > slave cryptodevs (QAT), to set this mode, the scheduler should have > > been attached 1 or more QATs. > > Could it be implemented on top of the eventdev API? > Not really. The eventdev API is for different types of scheduling between multiple sources that are all polling for packets, compared to this, which is more analgous - as I understand it - to the bonding PMD for ethdev. To make something like this work with an eventdev API you would need to use one of the following models: * have worker cores for offloading packets to the different crypto blocks pulling from the eventdev APIs. This would make it difficult to do any "smart" scheduling of crypto operations between the blocks, e.g. that one crypto instance may be better at certain types of operations than another. * move the logic in this driver into an existing eventdev instance, which uses the eventdev api rather than the crypto APIs and so has an extra level of "structure abstraction" that has to be worked though. It's just not really a good fit. So for this workload, I believe the pseudo-cryptodev instance is the best way to go. /Bruce