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 8ED017D14 for ; Fri, 25 Aug 2017 15:46:55 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Aug 2017 06:46:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,425,1498546800"; d="scan'208";a="141966254" Received: from silpixa00391537.ir.intel.com ([10.237.222.100]) by orsmga005.jf.intel.com with ESMTP; 25 Aug 2017 06:46:53 -0700 From: Amr Mokhtar To: dev@dpdk.org Cc: Amr Mokhtar Date: Fri, 25 Aug 2017 14:46:36 +0100 Message-Id: <1503668796-65832-2-git-send-email-amr.mokhtar@intel.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1503668796-65832-1-git-send-email-amr.mokhtar@intel.com> References: <1503668796-65832-1-git-send-email-amr.mokhtar@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=y Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [RFC] Wireless Base Band Device (bbdev) 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, 25 Aug 2017 13:46:56 -0000 This RFC describes a proposal for the Wireless Base Band Device (bbdev) in DPDK that abstracts HW accelerators based on FPGA and/or Fixed Function Accelerators that assist with LTE Physical Layer processing. Furthermore, it decouples the application from the compute-intensive wireless functions by abstracting their optimized libraries to appear as virtual bbdev devices. This makes bbdev a common programming framework that enables the same application code to be run on different systems with a single software architecture and programming model. If the system has hardware accelerators, they will be used, but if the system does not have hardware accelerators, software implementations can be used. The proposed bbdev is designed in a lookaside model where the operation to be processed is first enqueued asynchronously, and then the result is later dequeued similar to existing lookaside models. The proposed DPDK Base Band device framework meets the following requirements: 1. Enumerates bbdev hardware devices and load corresponding drivers. 2. Abstracts the same functionality through the optimized software libraries in case HW device is not existent. 3. Seamless interface for underlying operations (software or hardware) 4. Pluggable drivers for various parts of the packet processing 5. APIs to: - Probe wireless device capabilities and resources - Configure, start, stop, close and retrieve information of wireless devices - Configure, start, stop and retrieve information of operating queues - Enqueue/dequeue operations to wireless device queues - Reset and retrieve device and queue statistics - Support interrupts from HW The proposed approach is to have a single wireless device interface (bbdev) that is used for CRC, Rate (De)Matching and Turbo coding functionality supporting LTE physical Layer use cases. A general term for base band is used in the naming to allow for a combination of functions to be deployed for flexible and programmable devices are used such as FPGAs. The wireless Base Band device interface (bbdev) cannot be looked at as a subsidiary device class of cryptodev framework, bbdev follows similar design approach but it is different in definition and from operation perspective. The bbdev does not require the session management approach that cryptodev needs to function. Furthermore, bbdev is an abstraction framework that abstracts various device functions for numerous operations in the LTE physical layer like Turbo coding and rate matching, which cannot be considered operations of cryptography. Also, a bbdev device can support multiple wireless functions under one device ID. Other design approaches where considered during design selection phase like a wireless device interface is to have individual interfaces for each operation type within the LTE physical layer. This somewhat follows the cryptodev model, where the device interface can be used to perform a single class of operation type. However, it is difficult to map a device which performs multiple operations into this model. Consider the hardware accelerator that performs Rate (De)Matching, Turbo encoding/decoding (Turbo is a Forward Error Correction algorithm) and CRC handling. The device would have to register with three interfaces, and it would need three look-aside operations to do the processing (impacting performance). It is not correct to use it with a FEC (Forward Error Correction) device interface, as the device does more than that. Also, there is a wide range of FEC algorithms, many of which have no parameters or use-cases in common with Turbo (for example Reed-Solomon used in storage), so the usefulness of such an interface is questionable. The initial release of the bbdev includes CRC attachment, Turbo Coding and Rate (De)Matching supported in software. A device reports its capabilities when registering itself in the bbdev framework. With the aid of this capabilities mechanism, an application can query devices to discover which operations within the LTE physical layer they are capable of performing. Turbo code software library can be added as a virtual device to simulate the functionality being performed by the HW in case it is not existent or in case the application needs to use the two flavors to suit different types of workloads, for example: short payloads to use software Turbo and the HW for larger payloads. This software library is not part of DPDK mainstream, but it can be downloaded from an external link and linked to DPDK at compile time. For simplicity, the initial software devices are designed to perform the operation in the thread context that calls the enqueue function. The result of the operation will be put onto an internal rte_ring based queue, waiting for dequeue to be called. As device queues are not thread safe, the single-producer, single-consumer version of rte_ring queue can be used. A device ID represents a handle that is used by the application to refer to a specific instance of a bbdev device. The range of device IDs for bbdevs is not linked or related in any way with device IDs used for cryptodevs or ethdevs. The application can query how many bbdevs were discovered by the EAL through rte_bbdev_count() and then knows the range of valid device IDs that can be used for further device interaction. Once a device is present in the applications context, the application can discover some information about the exact device type and capabilities by calling rte_bbdev_info_get(dev_id, &info). Capabilities (in terms of operations supported, max number of queues, etc.) may be different for each device type so this is an important step for an application that is not highly coupled to a specific device type. >>From the application point of view, each instance of a bbdev device consists of one or more queues identified by queue IDs. While different devices may have different capabilities (e.g. support different operation types), all queues on a device support identical configuration possibilities. A queue is configured for only one type of operation and is configured at initializations time. When an operation is enqueued to a specific queue ID, the result is dequeued from the same queue ID. Configuration of a device has two different levels: configuration that applies to the whole device, and configuration that applies to a single queue. Device configuration is applied with rte_bbdev_configure(dev_id,num_queues,conf) and queue configuration is applied with rte_bbdev_queue_configure(dev_id, queue_id,conf). Note that, although all queues on a device support same capabilities, they can be configured differently and will then behave differently. After initialization, devices are in a stopped state, so must be started by the application. By default, all queues are started when the device is started, but they can be stopped individually. If an application is finished using a device it can close the device. Once closed, it cannot be restarted without reconfiguration. rte_bbdev_start(dev_id) rte_bbdev_queue_start(dev_id, queue_id) rte_bbdev_queue_stop(dev_id, queue_id) rte_bbdev_stop(dev_id) rte_bbdev_close(dev_id) Operations on a buffer (or buffers) are performed by an asynchronous API. Operations are enqueued to the device, and then dequeued later. Ordering of operations is maintained between the enqueue and dequeue. rte_bbdev_enqueue_ops(dev_id, queue_id, **ops, num_ops) rte_bbdev_dequeue_ops(dev_id, queue_id, **ops, num_ops) Queues are not thread-safe and the use of multiple queues or application-level locking is required for multi-threaded applications that share a device. Note that it is however acceptable for one thread to enqueue to a queue ID and another thread to dequeue from the same queue ID. This could be used to implement a multithreaded pipeline where each thread dequeues from a bbdev device, before enqueueing to the next. The number of queues supported by the device can be queried through rte_bbdev_info_get(). **ops is an array of pointers to struct rte_bbdev_op structures which contain all the details needed by the device to perform a single operation. As the bbdev interface supports different operation types (although individual devices may only support a subset of these), it contains a type field, and a union of parameters for each operation type. struct rte_bbdev_op { enum rte_bbdev_op_type type; … union { void *generic; struct rte_bbdev_op_turbo_dec *turbo_dec; struct rte_bbdev_op_turbo_enc *turbo_enc; }; }; Find the enclosed patch for the complete API specification, application- and driver-facing APIs. Looking forward to getting comments from both the application and driver Amr Mokhtar (1): Wireless Base Band Device (bbdev) lib/librte_bbdev/rte_bbdev.h | 636 +++++++++++++++++++++++++++++++++++++++ lib/librte_bbdev/rte_bbdev_op.h | 333 ++++++++++++++++++++ lib/librte_bbdev/rte_bbdev_pmd.h | 407 +++++++++++++++++++++++++ 3 files changed, 1376 insertions(+) create mode 100644 lib/librte_bbdev/rte_bbdev.h create mode 100644 lib/librte_bbdev/rte_bbdev_op.h create mode 100644 lib/librte_bbdev/rte_bbdev_pmd.h -- 1.9.1