 interface as the packet ingresses/egresses the platform. Bbdev and inter process communication The BBDEV standard defines a programming framework for offloading wireless workloads from a DPDK environment and has become the de-facto standard for offload of Linux-based stack implementations, either through hardware offload or (assumed optimized) software drivers. It includes an initialization stage including (offload) device discovery and configura- tion as well as offload task enqueue/dequeue APIs to be used in runtime by the wireless application itself. BBDEV and similar acceleration and IO APIs rely on communication queues that imple- ment Inter Processor Communication (IPC, Fig. 5-8) between two end points, typically Chapter 5 System software 195 physically connected via a PCIe link. IPC is a software mechanism for communicating between two entities but important to implement efficiently to achieve high performance. It is typically vendor provided through a set of libraries by the BSP. It consists of multiple channels (or bbdev queues) that define a 1:1 (unlikely 1: many given performance targets dictate no use of software locks for enqueue or dequeue operations) communication path between the two end points. The channel/queue is identi- fied by a unique ID. It is up to the application, how it is using the queues, whether they are sharing the same queue for different message type or using different queues for different message types. A model of an IPC channel implementation itself is shown below in Fig. 5-9: The characteristics of this channel are: For each channel, one end point is the producer and the other end point is the consumer. The producer sends the message and the consumer receives it. A channel has a single direction: from the producer to the consumer. One end point can be producer for one channel and consumer for another channel. So, for bidirectional communication at least two channels are needed. The channel is modeled as a circular queue (FIFO) of buffer descriptors (BDs), called a BD ring. A BD