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

Mokhtar, Amr amr.mokhtar at intel.com
Thu Oct 5 22:06:17 CEST 2017

Hi Thomas,
Kindly find my inline replies below..

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas at monjalon.net]
> Sent: Thursday 21 September 2017 15:35
> To: Mokhtar, Amr <amr.mokhtar at intel.com>
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [RFC] Wireless Base Band Device (bbdev)
> 25/08/2017 15:46, Amr Mokhtar:
> > 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.
> Looks interesting.
> When do you plan to send the first version?

Initial release has been pushed out. Feel free to have a look..

> The description done in this RFC is very complete and clear. Thanks I will ask few
> questions below.
> I assume packets are mbuf and Rx/Tx is done by ethdev. Right?


> Did you think about the API required for inline processing (i.e. bbdev combined
> with ethdev Rx/Tx)?

The current programming model is that ethdev is being used for input/output and
the bbdev is offloaded for lookaside acceleration.
The inline processing topic sounds interesting, this is something we can look at in
the future. Appreciate if you can share your thoughts in that regard.

> [...]
> > 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.
> So you decided to dedicate an API to the wireless base band functions, which is a
> functional split.
> I think the cryptodev API is a different split: it is targetting all processing which
> falls into the crypto category.
> Some crypto algorithms are associated to the wireless function, while others are
> more generic.
> It is very difficult to know how to split the scope of an API.

The way we view this functional split is:
 - If it is a cryptographic function -> cryptodev
 - If it is a Wireless L1 function, or in other words, more related to signal processing
   (coding, scrambling, modulation, ...) -> bbdev

> With the proposed scheme, if a wireless LTE device implements ZUC algorithm,
> we will have to support it in a cryptodev PMD while having a bbdev PMD for
> other wireless functions.
> Thoughts?

ZUC stays a cryptographic algorithm, it should go to cryptodev. It's true that ZUC
is a crypto algorithm used in the mobile wireless domain, but it is not related to signal
processing (Layer 1).
bbdev is targeting all or some of those wireless L1 functions.

> > 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.
> Do you mean that you do not plan to integrate the SW fallback for the turbo
> coding feature?

We DO actually plan to support SW-fallback of Turbo FEC in bbdev.

> Even if it is packaged separately, it could be integrated with bbdev API.

Right. It is packaged separately and link-able to bbdev library.

> [...]
> > 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.
> You must have an iterator macro to be able to manage id range with holes.
> I see it is already implemented as RTE_BBDEV_FOREACH.

Right. bbdev has the iterator macro.
But, sequential (gapless) device IDs only are currently supported in the first release.

> [...]
> > rte_bbdev_enqueue_ops(dev_id, queue_id, **ops, num_ops)
> > rte_bbdev_dequeue_ops(dev_id, queue_id, **ops, num_ops)
> [...]
> >
> > **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;
> > 	};
> > };
> I do not understand this part.
> It seems you want only two generic function to perform processing.
> I do not see the benefit.
> It is usually easier to have one function per type of processing.

Bbdev devices support Turbo encode and Turbo decode operations.
Both have separate sets of parameters and different functionalities, but
each queue is capable of doing either encode or decode (keep in mind
that this freedom of choice is only applicable before the q gets configured).

There is only one enqueue function for both enc/dec, and similarly one
dequeue function for both. The pmd internally interprets its argument
array of type "rte_bbdev_op" differently based on whether this q was set
up for enc or dec.
See this pseudo-code to give more projection of the idea:

enqueue(struct rte_bbdev_queue_data *q_data, struct rte_bbdev_op *op) {
    void *queue = q_data->queue_private;
    struct pmd_prv_queue *q = queue;

    switch (q->type) {
        struct rte_bbdev_op_turbo_enc *enc = op->turbo_enc;
        /* do encode */
        struct rte_bbdev_op_turbo_dec *dec = op->turbo_edec;
        /* do decode */

Since an enqueue was received on a decode queue, then the union is interpreted
as (rte_bbdev_op_turbo_dec), and vice versa for the encode (rte_bbdev_op_turbo_enc).

> I will continue the review with the code itself.


More information about the dev mailing list