[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