[dpdk-dev] [RFC] Wireless Base Band Device (bbdev)

[Mokhtar, Amr]

Hello,
Following on the proposal of bbdev, is there any comments. You feedback is highly appreciated.
May I propose to take this topic up to discussion by the Technical Board at next convenient time?

Regards,
Amr

> -----Original Message-----
> From: Mokhtar, Amr
> Sent: Friday 25 August 2017 14:47
> To: dev at dpdk.org
> Cc: Mokhtar, Amr <amr.mokhtar at intel.com>
> Subject: [RFC] Wireless Base Band Device (bbdev)
> 
> 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