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@dpdk.org
> Cc: Mokhtar, Amr <amr.mokh...@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
