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

Amr Mokhtar amr.mokhtar at intel.com
Fri Aug 25 15:46:36 CEST 2017


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



More information about the dev mailing list