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

Thomas Monjalon thomas at monjalon.net
Thu Sep 21 16:34:42 CEST 2017


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?

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)?

[...]
> 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.
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?

> 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?
Even if it is packaged separately, it could be integrated with bbdev API.

[...]
> 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.

[...]
> 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.

I will continue the review with the code itself.


More information about the dev mailing list