From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 6F5E05A8D for ; Tue, 28 Mar 2017 16:07:48 +0200 (CEST) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga105.fm.intel.com with ESMTP; 28 Mar 2017 07:07:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,236,1486454400"; d="scan'208";a="81493036" Received: from silpixa00381633.ir.intel.com (HELO silpixa00381633.ger.corp.intel.com) ([10.237.222.114]) by fmsmga005.fm.intel.com with ESMTP; 28 Mar 2017 07:07:46 -0700 From: Fan Zhang To: dev@dpdk.org Cc: pablo.de.lara.guarch@intel.com, sergio.gonzalez.monroy@intel.com, declan.doherty@intel.com Date: Tue, 28 Mar 2017 15:09:20 +0100 Message-Id: <1490710160-30089-4-git-send-email-roy.fan.zhang@intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1490710160-30089-1-git-send-email-roy.fan.zhang@intel.com> References: <1490710160-30089-1-git-send-email-roy.fan.zhang@intel.com> Subject: [dpdk-dev] [PATCH v3 3/3] doc: update cryptodev scheduler PMD documentation 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: Tue, 28 Mar 2017 14:07:48 -0000 This patch updates packet size based scheduling mode description. Signed-off-by: Fan Zhang --- doc/guides/cryptodevs/scheduler.rst | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/doc/guides/cryptodevs/scheduler.rst b/doc/guides/cryptodevs/scheduler.rst index 70fb62e..51f2a78 100644 --- a/doc/guides/cryptodevs/scheduler.rst +++ b/doc/guides/cryptodevs/scheduler.rst @@ -126,3 +126,17 @@ operation: among its slaves in a round-robin manner. This mode may help to fill the throughput gap between the physical core and the existing cryptodevs to increase the overall performance. + +* **CDEV_SCHED_MODE_PKT_SIZE_DISTR:** + + Packet-size based distribution mode, which 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. + + A typical usecase of this mode is with QAT cryptodev as primary and a + software cryptodev as secondary slave. This may help the application being + capable of processing extra crypto workload than what the sole QAT cryptodev + can handle, by making use of the available CPU cycles to deal with lesser + crypto workloads. -- 2.7.4