DPU

Resources on BlueField 2 Smart NICs · GitHub

NVMe-oF offload

3. Architecture
Each of the following DOCA core building blocks has its own structure and API. All DOCA core objects interact with one another to offer easy access to and management of BlueField capabilities.

3.1. DOCA Device
DOCA Device represents an available processing unit backed by hardware or software implementation.

DOCA Device supports two forms: The hardware device and the remote device.

Using DOCA Device, you may easily locate all the available local devices accessible by your system and all the remote devices accessible by a given local device. Each device found can be easily initiated using DOCA Device.

3. 架构
以下每个 DOCA 核心构建块都有自己的结构和 API。所有 DOCA 核心对象都相互交互，以提供对 BlueField 功能的轻松访问和管理。

3.1. DOCA设备
DOCA 设备代表由硬件或软件实现支持的可用处理单元。
DOCA Device支持两种形式：硬件设备和远程设备。
使用 DOCA 设备，您可以轻松找到系统可访问的所有可用本地设备以及给定本地设备可访问的所有远程设备。找到的每个设备都可以使用 DOCA 设备轻松启动。

3.2. DOCA Buffer
DOCA Buffer is used for reference data. It holds the information on a memory region that belongs to a DOCA memory map, and its descriptor is allocated from DOCA Buffer Inventory. Among other functions, it can be used to perform DMA operations.

3.3. DOCA Buffer Inventory
DOCA Buffer Inventory manages a pool of doca_buf objects. Each buffer obtained from an inventory is a descriptor that points to a memory region from a doca_mmap memory range of the user's choice.

3.4. DOCA Memory Map
DOCA Memory Map provides a centralized repository and orchestration of registration of several memory ranges for each device attached to the memory map.

Each memory map can represent memory from a single address space, such as host memory, DPU memory, etc.

DOCA Memory Map can be exported to allow accessibility of other applications to the memory ranges registered with the memory map.

DOCA Memory Map can be exported to allow accessibility of other applications to the memory ranges registered with the memory map. This allows selective sharing of specific memory ranges between applications on a single domain or across domains (e.g., between the DPU and the host).

3.4. DOCA 内存映射
DOCA 内存映射为连接到内存映射的每个设备提供了一个集中存储库和多个内存范围注册的编排。
每个内存映射可以表示来自单个地址空间的内存，例如主机内存、DPU 内存等。
DOCA 内存映射可以导出，以允许其他应用程序访问在内存映射中注册的内存范围。
DOCA 内存映射可以导出，以允许其他应用程序访问在内存映射中注册的内存范围。这允许在单个域上或跨域（例如，在 DPU 和主机之间）的应用程序之间选择性地共享特定内存范围。

3.5. DOCA Context
DOCA CTX is the base class of every data-path library in DOCA. It is a specific library/SDK instance object providing abstract data processing functionality. The library exposes events and/or jobs that manipulate data.

3.6. DOCA Work Queue
DOCA WorkQ provides progress engine service for DOCA CTXs. Once a DOCA WorkQ is added to a DOCA CTX, it can be used to submit jobs defined by the CTX and to progress and retrieve events from the CTX. The WorkQ is a thread-unsafe object and is considered the per-thread interface for communicating with CTXs.

3.7. DOCA Error
Provides information regarding different errors caused while using the DOCA core libraries.

3.5. DOCA 上下文
DOCA CTX 是 DOCA 中每个数据路径库的基类。它是提供抽象数据处理功能的特定库/SDK 实例对象。该库公开操作数据的事件和/或作业。

3.6. DOCA 工作队列
DOCA WorkQ 为 DOCA CTX 提供进度引擎服务。将 DOCA WorkQ 添加到 DOCA CTX 后，它可用于提交 CTX 定义的作业以及处理和检索来自 CTX 的事件。 WorkQ 是一个线程不安全的对象，被认为是与 CTX 通信的每线程接口。

3.7. DOCA错误
提供有关使用 DOCA 核心库时引起的不同错误的信息。

4. API
Refer to NVIDIA DOCA Libraries API Reference Manual, for more detailed information on the DOCA Core API.

The following sections provide additional details about the library API.

4.1. doca_devinfo
Note: All doca_devinfo operations are considered thread-safe.
The device information structure holds information about a device.

Devices are distinguished by their properties and type. Each device exposes a devinfo structure for querying properties and capabilities.

Available device properties:
Vendor unique identifier (VUID) – a unique string representation of a PCIe function. It is stable across reboots and is constant per device. Read-only property.
PCIe function address – returned as Bus Device Function format. Read-only property.
IPv4 address of the underlying network interface. Read-only property.
IPv6 address of the underlying network interface. Read-only property.
Network interface name. Read-only property.
IB device name. Read-only property.
A device can be one of the following types:
HW device – a PCIe function providing hardware capabilities
SW device – a virtual device providing software capabilities
To obtain a device information structure, you can use the doca_devinfo_list_create() function. Each device information structure can then be queried using doca_devinfo_property_get() while providing the devinfo.

Once a doca_devinfo is chosen, it can be used to obtain a doca_dev by opening one using doca_dev_open().

Once a device has been opened, it can be passed to DOCA Contexts for resource management.

4.1.1. doca_devinfo_list_create
This operation creates a list of available devices on the machine such that each device is represented by a device information structure.

The list must be destroyed after opening the desired devices using doca_devinfo_list_destroy(). This only releases unopened devices.

doca_error_t doca_devinfo_list_create(struct doca_devinfo ***devinfo_list);
Where:
devinfo_list – represents a pointer to the list of available device information. It is enough to allocate a struct doca_devinfo **<variable> and provide a pointer to it. The variable can then be used to iterate over the list as an array of pointers where the variable [index] can be used as the device information structure.
4.1.2. doca_devinfo_list_destroy
This operation destroys the list of device information obtained from doca_devinfo_list_create().

The device information list must be destroyed after opening the desired devices such that open devices are not destroyed.

doca_error_t doca_devinfo_list_destroy(struct doca_devinfo **devinfo_list);
Where:
devinfo_list – a list of device information structures obtained from doca_devinfo_list_create().
4.1.3. doca_devinfo_property_get
This operation gets the up-to-date value of a DOCA Device property.

This can be used to query DOCA Device properties.

doca_error_t doca_devinfo_property_get(const struct doca_devinfo *devinfo, enum doca_devinfo_property property, uint8_t *value, uint32_t size);
Where:
devinfo – DOCA Device information structure
property – the requested property to get. See enum doca_devinfo_property.
value – the value of the property (output parameter)
devinfo – the size of the property in bytes

4.1. 文档开发信息
注意：所有 doca_devinfo 操作都被视为线程安全的。
设备信息结构保存有关设备的信息。

设备通过其属性和类型来区分。每个设备都公开一个 devinfo 结构，用于查询属性和功能。

可用的设备属性：
供应商唯一标识符 (VUID) – PCIe 功能的唯一字符串表示形式。它在重新启动后保持稳定，并且每个设备都是恒定的。只读属性。
PCIe 函数地址 – 以总线设备函数格式返回。只读属性。
底层网络接口的 IPv4 地址。只读属性。
底层网络接口的 IPv6 地址。只读属性。
网络接口名称。只读属性。
IB 设备名称。只读属性。
设备可以是以下类型之一：
HW设备——提供硬件功能的PCIe功能
SW设备——提供软件功能的虚拟设备
要获取设备信息结构，可以使用 doca_devinfo_list_create() 函数。然后可以在提供 devinfo 的同时使用 doca_devinfo_property_get() 查询每个设备信息结构。

一旦选择了 doca_devinfo，就可以通过使用 doca_dev_open() 打开一个 doca_dev 来获取 doca_dev。

一旦设备被打开，它就可以被传递到 DOCA 上下文进行资源管理。

4.1.1. doca_devinfo_list_create
此操作创建机器上可用设备的列表，以便每个设备都由设备信息结构表示。

使用 doca_devinfo_list_destroy() 打开所需设备后必须销毁该列表。这仅释放未打开的设备。

doca_error_t doca_devinfo_list_create(struct doca_devinfo ***devinfo_list);
在哪里：
devinfo_list – 表示指向可用设备信息列表的指针。分配一个 struct doca_devinfo **<variable> 并提供指向它的指针就足够了。然后，该变量可用于将列表作为指针数组进行迭代，其中变量 [index] 可用作设备信息结构。
4.1.2. doca_devinfo_list_destroy
此操作会破坏从 doca_devinfo_list_create() 获取的设备信息列表。

打开所需设备后必须销毁设备信息列表，以免打开的设备被销毁。

doca_error_t doca_devinfo_list_destroy(struct doca_devinfo **devinfo_list);
在哪里：
devinfo_list – 从 doca_devinfo_list_create() 获取的设备信息结构列表。
4.1.3. doca_devinfo_property_get
此操作获取 DOCA 设备属性的最新值。

这可用于查询 DOCA 设备属性。

doca_error_t doca_devinfo_property_get(const struct doca_devinfo *devinfo, enum doca_devinfo_property property, uint8_t *value, uint32_t size);
在哪里：
devinfo – DOCA 设备信息结构
property – 请求获取的属性。请参阅枚举 doca_devinfo_property。
value – 属性的值（输出参数）
devinfo – 属性的大小（以字节为单位）

4.2. doca_dev
Note: All doca_dev operations are considered thread-safe.
The device structure holds active resources for use by different DOCA Contexts.

Each device can be represented as a doca_devinfo structure. To obtain a device information structure out of an open device, use doca_dev_as_devinfo().

The device manages resources that can be shared by different DOCA Contexts, while the devinfo structure is used for querying device properties.

The device can be passed to multiple contexts using doca_ctx_dev_add() while providing an open device.

4.2.1. doca_dev_open
This operation creates a device based on the device information.

Devices are a fundamental resource for each DOCA Context. After a device is opened, it can be passed to different DOCA Contexts.

Devices should be closed once they are no longer needed.

doca_error_t doca_dev_open(struct doca_devinfo *devinfo, struct doca_dev **dev);
Where:
devinfo – DOCA Device information structure with desired properties
dev – holds a DOCA device based on provided devinfo (output parameter)
4.2.2. doca_dev_close
This operation closes a device.

Devices should be closed once they are no longer needed.

doca_error_t doca_dev_close(struct doca_dev *dev);
Where:
dev – the DOCA Device to close
4.2.3. doca_dev_as_devinfo
This operation returns the DOCA Device information structure.

The returned information holds the same properties used to open the device.

doca_error_t doca_dev_as_devinfo(struct doca_dev *dev, struct doca_devinfo **devinfo);
Where:
dev – the DOCA Device
devinfo – holds returned DOCA Device information (output parameter)

4.2. 文档开发
注意：所有 doca_dev 操作都被认为是线程安全的。
设备结构持有活动资源以供不同的 DOCA 上下文使用。

每个设备都可以表示为 doca_devinfo 结构。要从打开的设备获取设备信息结构，请使用 doca_dev_as_devinfo()。

设备管理可以被不同DOCA上下文共享的资源，而devinfo结构用于查询设备属性。

在提供打开的设备时，可以使用 doca_ctx_dev_add() 将设备传递到多个上下文。

4.2.1. doca_dev_open
该操作根据设备信息创建设备。

设备是每个 DOCA 上下文的基本资源。设备打开后，可以传递给不同的DOCA上下文。

一旦不再需要设备，就应该将其关闭。

doca_error_t doca_dev_open(结构 doca_devinfo *devinfo, 结构 doca_dev **dev);
在哪里：
devinfo – 具有所需属性的 DOCA 设备信息结构
dev – 基于提供的 devinfo（输出参数）持有 DOCA 设备
4.2.2. doca_dev_close
此操作关闭设备。

一旦不再需要设备，就应该将其关闭。

doca_error_t doca_dev_close(struct doca_dev *dev);
在哪里：
dev – 要关闭的 DOCA 设备
4.2.3. doca_dev_as_devinfo
此操作返回 DOCA 设备信息结构。

返回的信息包含用于打开设备的相同属性。

doca_error_t doca_dev_as_devinfo(struct doca_dev *dev, struct doca_devinfo **devinfo);
在哪里：
dev – DOCA 设备
devinfo – 保存返回的 DOCA 设备信息（输出参数）

4.3. doca_devinfo_remote
Note: All doca_devinfo_remote operations are considered thread-safe.
The remote device information structure holds information about remote devices.

Remote devices are distinguished by their properties and type. Each device exposes a remote devinfo structure for querying properties and capabilities.

Remote devices can be obtained while running on the DPU only.

A remote device can only be a network device. That is, a representor of a network function managed by the host.

To obtain a remote device's information structure, use the doca_devinfo_remote_list_create() while providing a local device. Each remote device information structure can then be queried using doca_devinfo_remote_property_get() while providing the remote devinfo.

Once a doca_devinfo_remote is chosen, it can be used to obtain a doca_dev_remote by opening one using doca_dev_remote_open().

Once a remote device is opened, it can be used to refer to a device on the host machine.

4.3.1. doca_devinfo_remote_list_create
This operation creates a list of available devices on the machine such that each device is represented by a remote device information structure.

After opening the desired devices, the list should be destroyed using doca_devinfo_remote_list_destroy(). This only releases unopened devices.

This method can only be used on the DPU, where not all doca_devs have access to the devices on the host.

doca_error_t doca_devinfo_list_create(struct doca_dev *dev, struct doca_devinfo_remote ***devinfo_remote_list);
Where:
dev – represents a local device. The returned list holds information about devices on the host that are visible from this local device.
devinfo_remote_list – represents a pointer to the list of available remote device information. It is enough to allocate a struct doca_devinfo_remote **variable and provide a pointer to it. The variable can then be used to iterate over the list as an array of pointers, where the variable [index] can be used as the device information structure.
Note:dev can be closed after the remote list is created.
4.3.2. doca_devinfo_remote_list_destroy
This operation destroys the list of remote device information obtained from doca_devinfo_remote_list_create().

The list of remote device information should be destroyed after opening the desired remote devices such that remote devices that are open are not destroyed.

doca_error_t doca_devinfo_remote_list_destroy(struct doca_devinfo_remote **devinfo_remote_list);
Where:
devinfo_remote_list – a list of remote device information structures obtained from doca_devinfo_remote_list_create()
4.3.3. doca_devinfo_remote_property_get
This operation gets the up-to-date value of a DOCA Device property.

This can be used to query the remote DOCA Device's properties.

doca_error_t doca_devinfo_remote_property_get(const struct doca_devinfo_remote *devinfo_remote, enum doca_devinfo_remote_property property, uint8_t *value, uint32_t size);
Where:
devinfo_remote – the DOCA remote device information structure
property – the property to get. See enum doca_devinfo_remote_property.
value – the value of the property (output parameter)
size – the size of the property in bytes

4.3. doca_devinfo_remote
注意：所有 doca_devinfo_remote 操作都被视为线程安全的。
远程设备信息结构保存有关远程设备的信息。

远程设备通过其属性和类型来区分。每个设备都公开一个远程 devinfo 结构，用于查询属性和功能。

仅当在 DPU 上运行时才能获取远程设备。

远程设备只能是网络设备。即主机管理的网络功能的代表。

要获取远程设备的信息结构，请在提供本地设备时使用 doca_devinfo_remote_list_create()。然后可以使用 doca_devinfo_remote_property_get() 查询每个远程设备信息结构，同时提供远程 devinfo。

一旦选择了 doca_devinfo_remote，就可以通过使用 doca_dev_remote_open() 打开一个 doca_dev_remote 来获取 doca_dev_remote。

一旦远程设备被打开，它就可以用来引用主机上的设备。

4.3.1. doca_devinfo_remote_list_create
此操作创建机器上可用设备的列表，以便每个设备都由远程设备信息结构表示。

打开所需设备后，应使用 doca_devinfo_remote_list_destroy() 销毁列表。这仅释放未打开的设备。

此方法只能在 DPU 上使用，其中并非所有 doca_dev 都可以访问主机上的设备。

doca_error_t doca_devinfo_list_create(struct doca_dev *dev, struct doca_devinfo_remote ***devinfo_remote_list);
在哪里：
dev – 代表本地设备。返回的列表包含有关主机上从此本地设备可见的设备的信息。
devinfo_remote_list – 表示指向可用远程设备信息列表的指针。分配一个 struct doca_devinfo_remote **变量并提供指向它的指针就足够了。然后可以使用该变量作为指针数组来迭代列表，其中变量 [index] 可以用作设备信息结构。
注意：创建远程列表后可以关闭dev。
4.3.2. doca_devinfo_remote_list_destroy
此操作会破坏从 doca_devinfo_remote_list_create() 获取的远程设备信息列表。

在打开所需的远程设备后，应销毁远程设备信息列表，以便打开的远程设备不会被销毁。

doca_error_t doca_devinfo_remote_list_destroy(struct doca_devinfo_remote **devinfo_remote_list);
在哪里：
devinfo_remote_list – 从 doca_devinfo_remote_list_create() 获取的远程设备信息结构列表
4.3.3. doca_devinfo_remote_property_get
此操作获取 DOCA 设备属性的最新值。

这可用于查询远程 DOCA 设备的属性。

doca_error_t doca_devinfo_remote_property_get(const struct doca_devinfo_remote *devinfo_remote, enum doca_devinfo_remote_property 属性, uint8_t *value, uint32_t 大小);
在哪里：
devinfo_remote – DOCA 远程设备信息结构
财产——要获得的财产。请参阅枚举 doca_devinfo_remote_property。
value – 属性的值（输出参数）
size – 属性的大小（以字节为单位）

4.4. doca_dev_remote
Note: All doca_devinfo_remote operations are considered thread-safe.
The remote device structure holds active resources for use by different DOCA libraries.

Each remote device can be represented as a doca_devinfo_remote structure. To obtain a remote device information structure from an open remote device, use doca_dev_remote_as_devinfo().

The remote device manages resources that can be shared by different DOCA libraries, while the devinfo remote structure is used for querying remote device properties.

4.4.1. doca_dev_remote_open
This operation creates a remote device based on the remote device's information.

Opening a remote device activates its resources and prepares it for use by different libraries in DOCA.

Devices should be closed once they are no longer needed.

doca_error_t doca_dev_remote_open(struct doca_devinfo_remote *devinfo_remote, struct doca_dev_remote **dev_remote);
Where:
devinfo_remote – the DOCA remote device information structure with desired properties
dev_remote – holds a DOCA remote device based on provided devinfo (output parameter)
4.4.2. doca_dev_remote_close
This operation closes a remote device.

Devices should be closed once they are no longer needed.

doca_error_t doca_dev_remote_close(struct doca_dev_remote *dev_remote);
Where:
dev_remote – the DOCA remote device to close
4.4.3. doca_dev_as_devinfo
This operation returns the remote device information structure of the device.

The returned remote device information holds the same properties as the one used to open this device.

doca_error_t doca_dev_remote_as_devinfo(struct doca_dev_remote *dev_remote, struct doca_devinfo_remote **devinfo_remote);
Where:
dev_remote – the DOCA remote device
dev_remote – holds the returned DOCA remote device information (output parameter)

4.4. doca_dev_remote
注意：所有 doca_devinfo_remote 操作都被视为线程安全的。
远程设备结构保存活动资源以供不同的 DOCA 库使用。

每个远程设备都可以表示为 doca_devinfo_remote 结构。要从打开的远程设备获取远程设备信息结构，请使用 doca_dev_remote_as_devinfo()。

远程设备管理可以被不同DOCA库共享的资源，而devinfo远程结构体用于查询远程设备属性。

3.1. DOCA Device
DOCA Device represents an available processing unit backed by hardware or software implementation.

DOCA Device supports two forms: The hardware device and the remote device.

3. 架构
以下每个 DOCA 核心构建块都有自己的结构和 API。所有 DOCA 核心对象都相互交互，以提供对 BlueField 功能的轻松访问和管理。

3.2. DOCA Buffer
DOCA Buffer is used for reference data. It holds the information on a memory region that belongs to a DOCA memory map, and its descriptor is allocated from DOCA Buffer Inventory. Among other functions, it can be used to perform DMA operations.

3.3. DOCA Buffer Inventory
DOCA Buffer Inventory manages a pool of doca_buf objects. Each buffer obtained from an inventory is a descriptor that points to a memory region from a doca_mmap memory range of the user's choice.

3.4. DOCA Memory Map
DOCA Memory Map provides a centralized repository and orchestration of registration of several memory ranges for each device attached to the memory map.

Each memory map can represent memory from a single address space, such as host memory, DPU memory, etc.

DOCA Memory Map can be exported to allow accessibility of other applications to the memory ranges registered with the memory map.

3.7. DOCA Error
Provides information regarding different errors caused while using the DOCA core libraries.

3.5. DOCA 上下文
DOCA CTX 是 DOCA 中每个数据路径库的基类。它是提供抽象数据处理功能的特定库/SDK 实例对象。该库公开操作数据的事件和/或作业。

3.7. DOCA错误
提供有关使用 DOCA 核心库时引起的不同错误的信息。

4. API
Refer to NVIDIA DOCA Libraries API Reference Manual, for more detailed information on the DOCA Core API.

The following sections provide additional details about the library API.

4.1. doca_devinfo
Note: All doca_devinfo operations are considered thread-safe.
The device information structure holds information about a device.

Devices are distinguished by their properties and type. Each device exposes a devinfo structure for querying properties and capabilities.

Once a doca_devinfo is chosen, it can be used to obtain a doca_dev by opening one using doca_dev_open().

Once a device has been opened, it can be passed to DOCA Contexts for resource management.

4.1.1. doca_devinfo_list_create
This operation creates a list of available devices on the machine such that each device is represented by a device information structure.

The list must be destroyed after opening the desired devices using doca_devinfo_list_destroy(). This only releases unopened devices.

The device information list must be destroyed after opening the desired devices such that open devices are not destroyed.

doca_error_t doca_devinfo_list_destroy(struct doca_devinfo **devinfo_list);
Where:
devinfo_list – a list of device information structures obtained from doca_devinfo_list_create().
4.1.3. doca_devinfo_property_get
This operation gets the up-to-date value of a DOCA Device property.

This can be used to query DOCA Device properties.

4.1. 文档开发信息
注意：所有 doca_devinfo 操作都被视为线程安全的。
设备信息结构保存有关设备的信息。

设备通过其属性和类型来区分。每个设备都公开一个 devinfo 结构，用于查询属性和功能。

一旦选择了 doca_devinfo，就可以通过使用 doca_dev_open() 打开一个 doca_dev 来获取 doca_dev。

一旦设备被打开，它就可以被传递到 DOCA 上下文进行资源管理。

4.1.1. doca_devinfo_list_create
此操作创建机器上可用设备的列表，以便每个设备都由设备信息结构表示。

使用 doca_devinfo_list_destroy() 打开所需设备后必须销毁该列表。这仅释放未打开的设备。

打开所需设备后必须销毁设备信息列表，以免打开的设备被销毁。

这可用于查询 DOCA 设备属性。

4.2. doca_dev
Note: All doca_dev operations are considered thread-safe.
The device structure holds active resources for use by different DOCA Contexts.

Each device can be represented as a doca_devinfo structure. To obtain a device information structure out of an open device, use doca_dev_as_devinfo().

The device manages resources that can be shared by different DOCA Contexts, while the devinfo structure is used for querying device properties.

The device can be passed to multiple contexts using doca_ctx_dev_add() while providing an open device.

4.2.1. doca_dev_open
This operation creates a device based on the device information.

Devices are a fundamental resource for each DOCA Context. After a device is opened, it can be passed to different DOCA Contexts.

Devices should be closed once they are no longer needed.

doca_error_t doca_dev_open(struct doca_devinfo *devinfo, struct doca_dev **dev);
Where:
devinfo – DOCA Device information structure with desired properties
dev – holds a DOCA device based on provided devinfo (output parameter)
4.2.2. doca_dev_close
This operation closes a device.

Devices should be closed once they are no longer needed.

doca_error_t doca_dev_close(struct doca_dev *dev);
Where:
dev – the DOCA Device to close
4.2.3. doca_dev_as_devinfo
This operation returns the DOCA Device information structure.

The returned information holds the same properties used to open the device.

doca_error_t doca_dev_as_devinfo(struct doca_dev *dev, struct doca_devinfo **devinfo);
Where:
dev – the DOCA Device
devinfo – holds returned DOCA Device information (output parameter)

4.2. 文档开发
注意：所有 doca_dev 操作都被认为是线程安全的。
设备结构持有活动资源以供不同的 DOCA 上下文使用。

每个设备都可以表示为 doca_devinfo 结构。要从打开的设备获取设备信息结构，请使用 doca_dev_as_devinfo()。

设备管理可以被不同DOCA上下文共享的资源，而devinfo结构用于查询设备属性。

在提供打开的设备时，可以使用 doca_ctx_dev_add() 将设备传递到多个上下文。

4.2.1. doca_dev_open
该操作根据设备信息创建设备。

设备是每个 DOCA 上下文的基本资源。设备打开后，可以传递给不同的DOCA上下文。

一旦不再需要设备，就应该将其关闭。

doca_error_t doca_dev_close(struct doca_dev *dev);
在哪里：
dev – 要关闭的 DOCA 设备
4.2.3. doca_dev_as_devinfo
此操作返回 DOCA 设备信息结构。

返回的信息包含用于打开设备的相同属性。

doca_error_t doca_dev_as_devinfo(struct doca_dev *dev, struct doca_devinfo **devinfo);
在哪里：
dev – DOCA 设备
devinfo – 保存返回的 DOCA 设备信息（输出参数）

4.3. doca_devinfo_remote
Note: All doca_devinfo_remote operations are considered thread-safe.
The remote device information structure holds information about remote devices.

Remote devices are distinguished by their properties and type. Each device exposes a remote devinfo structure for querying properties and capabilities.

Remote devices can be obtained while running on the DPU only.

A remote device can only be a network device. That is, a representor of a network function managed by the host.

Once a doca_devinfo_remote is chosen, it can be used to obtain a doca_dev_remote by opening one using doca_dev_remote_open().

Once a remote device is opened, it can be used to refer to a device on the host machine.

4.3.1. doca_devinfo_remote_list_create
This operation creates a list of available devices on the machine such that each device is represented by a remote device information structure.

After opening the desired devices, the list should be destroyed using doca_devinfo_remote_list_destroy(). This only releases unopened devices.

This method can only be used on the DPU, where not all doca_devs have access to the devices on the host.

doca_error_t doca_devinfo_list_create(struct doca_dev *dev, struct doca_devinfo_remote ***devinfo_remote_list);
Where:
dev – represents a local device. The returned list holds information about devices on the host that are visible from this local device.
devinfo_remote_list – represents a pointer to the list of available remote device information. It is enough to allocate a struct doca_devinfo_remote **variable and provide a pointer to it. The variable can then be used to iterate over the list as an array of pointers, where the variable [index] can be used as the device information structure.
Note:dev can be closed after the remote list is created.
4.3.2. doca_devinfo_remote_list_destroy
This operation destroys the list of remote device information obtained from doca_devinfo_remote_list_create().

The list of remote device information should be destroyed after opening the desired remote devices such that remote devices that are open are not destroyed.

doca_error_t doca_devinfo_remote_list_destroy(struct doca_devinfo_remote **devinfo_remote_list);
Where:
devinfo_remote_list – a list of remote device information structures obtained from doca_devinfo_remote_list_create()
4.3.3. doca_devinfo_remote_property_get
This operation gets the up-to-date value of a DOCA Device property.

This can be used to query the remote DOCA Device's properties.

4.3. doca_devinfo_remote
注意：所有 doca_devinfo_remote 操作都被视为线程安全的。
远程设备信息结构保存有关远程设备的信息。

远程设备通过其属性和类型来区分。每个设备都公开一个远程 devinfo 结构，用于查询属性和功能。

仅当在 DPU 上运行时才能获取远程设备。

远程设备只能是网络设备。即主机管理的网络功能的代表。

一旦选择了 doca_devinfo_remote，就可以通过使用 doca_dev_remote_open() 打开一个 doca_dev_remote 来获取 doca_dev_remote。

一旦远程设备被打开，它就可以用来引用主机上的设备。

4.3.1. doca_devinfo_remote_list_create
此操作创建机器上可用设备的列表，以便每个设备都由远程设备信息结构表示。

打开所需设备后，应使用 doca_devinfo_remote_list_destroy() 销毁列表。这仅释放未打开的设备。

此方法只能在 DPU 上使用，其中并非所有 doca_dev 都可以访问主机上的设备。

doca_error_t doca_devinfo_list_create(struct doca_dev *dev, struct doca_devinfo_remote ***devinfo_remote_list);
在哪里：
dev – 代表本地设备。返回的列表包含有关主机上从此本地设备可见的设备的信息。
devinfo_remote_list – 表示指向可用远程设备信息列表的指针。分配一个 struct doca_devinfo_remote **变量并提供指向它的指针就足够了。然后可以使用该变量作为指针数组来迭代列表，其中变量 [index] 可以用作设备信息结构。
注意：创建远程列表后可以关闭dev。
4.3.2. doca_devinfo_remote_list_destroy
此操作会破坏从 doca_devinfo_remote_list_create() 获取的远程设备信息列表。

在打开所需的远程设备后，应销毁远程设备信息列表，以便打开的远程设备不会被销毁。

doca_error_t doca_devinfo_remote_list_destroy(struct doca_devinfo_remote **devinfo_remote_list);
在哪里：
devinfo_remote_list – 从 doca_devinfo_remote_list_create() 获取的远程设备信息结构列表
4.3.3. doca_devinfo_remote_property_get
此操作获取 DOCA 设备属性的最新值。

这可用于查询远程 DOCA 设备的属性。

4.4. doca_dev_remote
Note: All doca_devinfo_remote operations are considered thread-safe.
The remote device structure holds active resources for use by different DOCA libraries.

Each remote device can be represented as a doca_devinfo_remote structure. To obtain a remote device information structure from an open remote device, use doca_dev_remote_as_devinfo().

The remote device manages resources that can be shared by different DOCA libraries, while the devinfo remote structure is used for querying remote device properties.

4.4.1. doca_dev_remote_open
This operation creates a remote device based on the remote device's information.

Opening a remote device activates its resources and prepares it for use by different libraries in DOCA.

Devices should be closed once they are no longer needed.

doca_error_t doca_dev_remote_open(struct doca_devinfo_remote *devinfo_remote, struct doca_dev_remote **dev_remote);
Where:
devinfo_remote – the DOCA remote device information structure with desired properties
dev_remote – holds a DOCA remote device based on provided devinfo (output parameter)
4.4.2. doca_dev_remote_close
This operation closes a remote device.

Devices should be closed once they are no longer needed.

doca_error_t doca_dev_remote_close(struct doca_dev_remote *dev_remote);
Where:
dev_remote – the DOCA remote device to close
4.4.3. doca_dev_as_devinfo
This operation returns the remote device information structure of the device.

The returned remote device information holds the same properties as the one used to open this device.

4.4. doca_dev_remote
注意：所有 doca_devinfo_remote 操作都被视为线程安全的。
远程设备结构保存活动资源以供不同的 DOCA 库使用。

每个远程设备都可以表示为 doca_devinfo_remote 结构。要从打开的远程设备获取远程设备信息结构，请使用 doca_dev_remote_as_devinfo()。

远程设备管理可以被不同DOCA库共享的资源，而devinfo远程结构体用于查询远程设备属性。

4.4.1. doca_dev_remote_open
此操作根据远程设备的信息创建远程设备。

打开远程设备会激活其资源并准备好供 DOCA 中的不同库使用。

一旦不再需要设备，就应该将其关闭。

doca_error_t doca_dev_remote_open(结构 doca_devinfo_remote *devinfo_remote, 结构 doca_dev_remote **dev_remote);
在哪里：
devinfo_remote – 具有所需属性的 DOCA 远程设备信息结构
dev_remote – 根据提供的 devinfo（输出参数）保存 DOCA 远程设备
4.4.2. doca_dev_remote_close
此操作关闭远程设备。

一旦不再需要设备，就应该将其关闭。

doca_error_t doca_dev_remote_close(struct doca_dev_remote *dev_remote);
在哪里：
dev_remote – 要关闭的 DOCA 远程设备
4.4.3. doca_dev_as_devinfo
该操作返回设备的远程设备信息结构。

返回的远程设备信息与用于打开该设备的信息具有相同的属性。

doca_error_t doca_dev_remote_as_devinfo(结构 doca_dev_remote *dev_remote, 结构 doca_devinfo_remote **devinfo_remote);
在哪里：
dev_remote – DOCA 远程设备
dev_remote – 保存返回的DOCA远程设备信息（输出参数）

4.5. doca_buf
Note: All doca_buf operations are considered thread-unsafe.
The DOCA Buffer structure is a descriptor that holds information on a memory region, defined by the address in which the memory region begins, and the length of the memory region in bytes. The address and length of the memory region are set when the buffer is created. They then become read-only.

4.5.1. doca_buf_head_get
This operation returns the address of the memory region that the buffer points to.

doca_error_t doca_buf_head_get(struct doca_buf *buf, uint8_t **head);
Where:
buf – the DOCA Buffer structure
head – the address of the memory region that the buffer points to (output parameter)
4.5.2. doca_buf_len_get
This operation returns the size of the memory region pointed by the buffer in bytes.

doca_error_t doca_buf_len_get(struct doca_buf *buf, size_t *len);
Where:
buf – the DOCA Buffer structure
len – the length of the memory region pointed by the buffer (output parameter)
4.5.3. doca_buf_refcount_rm
This operation decreases doca_buf reference count. Once it reaches zero, the function destroys the doca_buf object.

doca_error_t doca_buf_refcount_rm(struct doca_buf *buf, uint16_t *refcount);
Where:
buf – the DOCA Buffer structure
refcount – the doca_buf reference count value before this operation took place (output parameter)
4.5.4. doca_buf_refcount_get
This operation returns doca_buf reference count value.

doca_error_t doca_buf_refcount_get(struct doca_buf *buf, uint16_t *refcount);
Where:
buf – the DOCA Buffer structure
refcount – the doca_buf reference count value (output parameter)

4.5. 多卡缓冲区
注意：所有 doca_buf 操作都被认为是线程不安全的。
DOCA Buffer 结构是一个描述符，保存有关内存区域的信息，由内存区域开始的地址以及内存区域的长度（以字节为单位）定义。内存区域的地址和长度是在创建缓冲区时设置的。然后它们将变为只读。

4.5.1. doca_buf_head_get
该操作返回缓冲区指向的内存区域的地址。

doca_error_t doca_buf_head_get(struct doca_buf *buf, uint8_t **head);
在哪里：
buf – DOCA 缓冲区结构
head – 缓冲区指向的内存区域的地址（输出参数）
4.5.2. doca_buf_len_get
此操作返回缓冲区指向的内存区域的大小（以字节为单位）。

doca_error_t doca_buf_len_get(struct doca_buf *buf, size_t *len);
在哪里：
buf – DOCA 缓冲区结构
len – 缓冲区指向的内存区域的长度（输出参数）
4.5.3. doca_buf_refcount_rm
此操作会减少 doca_buf 引用计数。一旦达到零，该函数就会销毁 doca_buf 对象。

doca_error_t doca_buf_refcount_rm(struct doca_buf *buf, uint16_t *refcount);
在哪里：
buf – DOCA 缓冲区结构
refcount – 此操作发生之前的 doca_buf 引用计数值（输出参数）
4.5.4. doca_buf_refcount_get
此操作返回 doca_buf 引用计数值。

doca_error_t doca_buf_refcount_get(struct doca_buf *buf, uint16_t *refcount);
在哪里：
buf – DOCA 缓冲区结构
refcount – doca_buf 引用计数值（输出参数）

4.6. doca_buf_inventory
Note: All doca_buf_inventory operations are considered thread-unsafe.
The DOCA buffer inventory structure manages a pool of doca_buf objects. After creating doca_buf_inventory, the user must start the buffer inventory using doca_buf_inventory_start() function.

When creating doca_buf_inventory, the returned object can be manipulated with doca_buf_inventory_property_set() API. Once all required attributes are set, it should be reconfigured and adjusted to match the settings in doca_buf_inventory_start().

The following operations become possible only after start:
Retrieval of free elements from the inventory using doca_buf_inventory_buf_by_addr()
Duplicating the content of a buffer into a buffer allocated from the inventory using doca_buf_inventory_buf_dup()
Setting the properties of the inventory using doca_buf_inventory_property_set() is not possible after first starting the buffer inventory object.

Each buffer allocated by doca_buf_inventory_buf_by_addr() points to a memory region of the users' choice.

Un-started/stopped buffer inventory rejects all attempts to allocate new DOCA Buffers, regardless of the number of free elements.

doca_buf_inventory_create
This operation allocates DOCA buffer inventory with the given attributes.

doca_error_t doca_buf_inventory_create(const char *name, size_t num_elements, uint32_t extensions, struct doca_buf_inventory **buf_inventory);
Where:
name – name of created DOCA buffer inventory
num_elements – number of elements in the inventory
num_elements – bitmap of extensions enabled for the inventory described in doca_buf.h
num_elements – DOCA buffer inventory on success (output parameter)
4.6.2. doca_buf_inventory_destroy
This operation destroys the DOCA buffer inventory structure and frees its memory. Before calling doca_buf_inventory_destroy all allocated buffers must be returned to the inventory.

doca_error_t doca_buf_inventory_destroy(struct doca_buf_inventory *inventory);
Where:
inventory – DOCA buffer inventory to destroy
4.6.3. doca_buf_inventory_property_set
This operation sets the value of a DOCA buffer inventory property.

doca_error_t doca_buf_inventory_property_set(struct doca_buf_inventory *inventory, enum doca_buf_inventory_property property, const uint8_t *value, uint32_t size);
Where:
inventory – DOCA buffer inventory structure
property – the requested property to set. See enum doca_buf_inventory_property.
value – the new value of the property
size – the size of the property in bytes
Note: All DOCA buffer inventory properties available at this stage are read-only properties.
4.6.4. doca_buf_inventory_property_get
This operation gets the up-to-date value of a DOCA buffer inventory property.

doca_error_t doca_buf_inventory_property_get(struct doca_buf_inventory *inventory, enum doca_buf_inventory_property property, const uint8_t *value, uint32_t size);
Where:
inventory – DOCA buffer inventory structure
property – the requested property to get. See enum doca_buf_inventory_property.
value – the value of the property (output parameter)
size – the size of the property in bytes
4.6.5. doca_buf_inventory_start
This operation starts DOCA buffer inventory.

doca_error_t doca_buf_inventory_start(struct doca_buf_inventory *inventory);
Where:
inventory – DOCA buffer inventory to start
4.6.6. doca_buf_inventory_stop
This operation stops DOCA buffer inventory.

doca_error_t doca_buf_inventory_stop(struct doca_buf_inventory *inventory);
Where:
inventory – DOCA buffer inventory to stop

4.6. doca_buf_inventory
注意：所有 doca_buf_inventory 操作都被视为线程不安全。
DOCA 缓冲区库存结构管理 doca_buf 对象池。创建 doca_buf_inventory 后，用户必须使用 doca_buf_inventory_start() 函数启动缓冲区清单。

创建 doca_buf_inventory 时，可以使用 doca_buf_inventory_property_set() API 操作返回的对象。一旦设置了所有必需的属性，就应该重新配置和调整以匹配 doca_buf_inventory_start() 中的设置。

只有启动后才能进行以下操作：
使用 doca_buf_inventory_buf_by_addr() 从库存中检索空闲元素
使用 doca_buf_inventory_buf_dup() 将缓冲区的内容复制到从清单分配的缓冲区中
首次启动缓冲区清单对象后，无法使用 doca_buf_inventory_property_set() 设置清单的属性。

doca_buf_inventory_buf_by_addr() 分配的每个缓冲区都指向用户选择的内存区域。

未启动/停止的缓冲区库存会拒绝所有分配新 DOCA 缓冲区的尝试，无论空闲元素的数量有多少。

doca_buf_inventory_create
此操作分配具有给定属性的 DOCA 缓冲区库存。

doca_error_t doca_buf_inventory_create(const char *name, size_t num_elements, uint32_t 扩展, struct doca_buf_inventory **buf_inventory);
在哪里：
name – 创建的 DOCA 缓冲区清单的名称
num_elements – 库存中的元素数量
num_elements – 为 doca_buf.h 中描述的清单启用的扩展位图
num_elements – 成功时的 DOCA 缓冲区库存（输出参数）
4.6.2. doca_buf_inventory_destroy
此操作会破坏 DOCA 缓冲区库存结构并释放其内存。在调用 doca_buf_inventory_destroy 之前，所有分配的缓冲区必须返回到清单中。

doca_error_t doca_buf_inventory_destroy(struct doca_buf_inventory *inventory);
在哪里：
库存 – DOCA 缓冲库存以销毁
4.6.3. doca_buf_inventory_property_set
此操作设置 DOCA 缓冲区库存属性的值。

doca_error_t doca_buf_inventory_property_set(struct doca_buf_inventory *inventory, enum doca_buf_inventory_property property, const uint8_t *value, uint32_t size);
在哪里：
库存 – DOCA 缓冲库存结构
property – 请求设置的属性。请参阅枚举 doca_buf_inventory_property。
value – 财产的新价值
size – 属性的大小（以字节为单位）
注意：此阶段可用的所有 DOCA 缓冲区库存属性都是只读属性。
4.6.4. doca_buf_inventory_property_get
此操作获取 DOCA 缓冲区库存属性的最新值。

doca_error_t doca_buf_inventory_property_get(struct doca_buf_inventory *inventory, enum doca_buf_inventory_property property, const uint8_t *value, uint32_t size);
在哪里：
库存 – DOCA 缓冲库存结构
property – 请求获取的属性。请参阅枚举 doca_buf_inventory_property。
value – 属性的值（输出参数）
size – 属性的大小（以字节为单位）
4.6.5。 doca_buf_inventory_start
此操作启动 DOCA 缓冲区库存。

doca_error_t doca_buf_inventory_start(struct doca_buf_inventory *inventory);
在哪里：
库存 – DOCA 缓冲库存启动
4.6.6。 doca_buf_inventory_stop
此操作会停止 DOCA 缓冲区库存。

doca_error_t doca_buf_inventory_stop(struct doca_buf_inventory *inventory);
在哪里：
库存 – DOCA 缓冲库存停止

4.6.7. doca_buf_inventory_buf_by_addr
This operation takes a single DOCA buffer from the DOCA buffer inventory and points it to a memory region from the DOCA memory map using the given addr and len arguments.

The given address and length must be contained in one of the memory ranges of the DOCA memory map. The operation fails if there is no such suitable memory range.

doca_error_t doca_buf_inventory_buf_by_addr(struct doca_buf_inventory *inventory, struct doca_mmap *mmap, char *addr, size_t len, struct doca_buf **buf);
Where:
inventory – DOCA buffer inventory structure
mmap – DOCA memory map structure
addr – the address of the memory region for the new doca_buf to point to
len – the length of the memory region for the new doca_buf to point to in bytes
buf – DOCA buffer object (output parameter)
4.6.8. doca_buf_inventory_buf_dup
This operation duplicates the source buffer by taking a new destination buffer from the given DOCA buffer inventory and copying the source buffer content to the destination buffer.

doca_error_t doca_buf_inventory_buf_dup(struct doca_buf_inventory *inventory, const struct doca_buf *src_buf, struct doca_buf **dst_buf);
Where:
inventory – DOCA buffer inventory structure
src_buf – the buffer to duplicate
dst_buf – the duplicated DOCA buffer (output parameter)

4.6.7. doca_buf_inventory_buf_by_addr
此操作从 DOCA 缓冲区清单中获取单个 DOCA 缓冲区，并使用给定的 addr 和 len 参数将其指向 DOCA 内存映射中的内存区域。

给定的地址和长度必须包含在 DOCA 内存映射的内存范围之一中。如果没有这样合适的内存范围，操作将失败。

doca_error_t doca_buf_inventory_buf_by_addr(struct doca_buf_inventory *inventory, struct doca_mmap *mmap, char *addr, size_t len, struct doca_buf **buf);
在哪里：
库存 – DOCA 缓冲库存结构
mmap——DOCA内存映射结构
addr – 新 doca_buf 指向的内存区域的地址
len – 新 doca_buf 指向的内存区域的长度（以字节为单位）
buf – DOCA 缓冲区对象（输出参数）
4.6.8。 doca_buf_inventory_buf_dup
此操作通过从给定 DOCA 缓冲区库存中获取新的目标缓冲区并将源缓冲区内容复制到目标缓冲区来复制源缓冲区。

doca_error_t doca_buf_inventory_buf_dup(struct doca_buf_inventory *inventory, const struct doca_buf *src_buf, struct doca_buf **dst_buf);
在哪里：
库存 – DOCA 缓冲库存结构
src_buf – 要复制的缓冲区
dst_buf – 复制的 DOCA 缓冲区（输出参数）

4.7. doca_mmap
Note: All doca_mmap operations are considered thread-unsafe.
The DOCA memory map (mmap) structure points to a collection of memory ranges from a single address space; either the host or DPU memory.

Definitions:
Memory range – virtually contiguous fracture of memory space defined by address and length
Chunk – local system memory range
Remote chunk – remote system memory range
Each DOCA memory map has defined properties:
DOCA memory map name set on creation. Read-only property.
The maximum number of chunks that can be populated. The default value is 1 if not set by the user before doca_mmap_start. Once this limit is reached, further chunk populations fail. If mmap is from an export, then the number of remote chunks is returned.
The maximum number of devices that can be added to the doca_mmap. The default value is 1 if not set by the user before doca_mmap_start. Once this limit is reached, further device additions fail.
The number of DOCA buffers pointing to memory ranges in the doca_mmap. Read-only property.
Exported flag. Set to true if the doca_mmap is exported, false otherwise. Read-only property.
From export flag. Set to true if the doca_mmap has been created from an export, false otherwise. Read-only property.
Access flags. The doca_mmap access flags. See enum doca_mmap_access_flags for more.
The DOCA memory map object can be manipulated with doca_mmap_property_set() API. Once all required DOCA memory map attributes are set, it should be reconfigured and adjusted to match the settings in doca_mmap_start().

The following operations become possible only after start:
Adding a device to doca_mmap using doca_mmap_dev_add()
Removing a device from doca_mmap using doca_mmap_dev_rm()
Adding a memory range to the doca_mmap using doca_mmap_populate()
Exporting the doca_mmap using doca_mmap_export()
Mapping doca_buf structures to the memory ranges using doca_buf_inventory_buf_by_addr() or doca_buf_inventory_buf_dup()
Setting the properties of doca_mmap using doca_mmap_property_set() is no longer possible after starting the memory map (mmap) object.

The following are not possible on exported doca_mmap or on doca_mmap that has been created from export:
Setting the properties of the doca_mmap using doca_mmap_property_set()
Adding a device to the doca_mmap using doca_mmap_dev_add()
Removing a device to the doca_mmap using doca_mmap_dev_rm()
Adding a memory range to the doca_mmap using doca_mmap_populate()
Exporting the doca_mmap using doca_mmap_export()
4.7.1. doca_mmap_create
This operation allocates zero-size memory map object with default/unset attributes.

doca_error_t doca_mmap_create(const char *name, struct doca_mmap **mmap);
Where:
name – name of created DOCA memory map
mmap – DOCA memory map structure with default/unset attributes on success
4.7.2. doca_mmap_destroy
This operation destroys DOCA memory map structure and frees its memory. Before calling doca_mmap_destroy, all allocated buffers must be returned to the doca_mmap.

doca_error_t doca_mmap_destroy(struct doca_mmap *mmap);
Where:
mmap – DOCA memory map to destroy
4.7.3. doca_mmap_property_set
This operation sets the value of a DOCA memory map property.

doca_error_t doca_mmap_property_set(struct doca_mmap *mmap, enum doca_mmap_property property, const uint8_t *value, uint32_t size);
Where:
mmap – DOCA memory map structure
property – the requested property to set. See enum doca_mmap_property.
value – the new value of the property
size – the size of the property in bytes
4.7.4. doca_mmap_property_get
This operation gets the up-to-date value of a DOCA memory map property.

doca_error_t doca_mmap_property_get(struct doca_mmap *mmap, enum doca_mmap_property property, const uint8_t *value, uint32_t size);
Where:
mmap – DOCA memory map structure
property – the requested property to get. See enum doca_mmap_property.
value – the value of the property (output parameter)
size – the size of the property in bytes
4.7.5. doca_mmap_start
This operation starts the DOCA memory map.

doca_error_t doca_mmap_start(struct doca_mmap *mmap);
Where:
mmap – DOCA memory map to start
4.7.6. doca_mmap_stop
This operation stops the DOCA memory map.

doca_error_t doca_mmap_stop(struct doca_mmap *mmap);
Where:
mmap – DOCA memory map to stop
4.7.7. doca_mmap_dev_add
This operation registers DOCA memory map on the given device.

If the doca_mmap has been populated before this operation took place, the function performs memory registration of the new device added with each of the memory ranges attached to the doca_mmap.

doca_error_t doca_mmap_dev_add(struct doca_mmap *mmap, struct doca_dev *dev);
Where:
mmap – DOCA memory map structure
dev – the DOCA device object that should be registered to the doca_mmap
4.7.8. doca_mmap_dev_rm
This operation deregisters the given device from the DOCA memory map.

If the doca_mmap contains memory ranges, the function performs memory deregistration of the given device to each of them.

doca_error_t doca_mmap_dev_rm(struct doca_mmap *mmap, struct doca_dev *dev);
Where:
mmap – DOCA memory map structure
dev – the DOCA device object that should be deregistered from the doca_mmap. The device must be a device previously added to the memory map via doca_mmap_dev_add().

4.7.9. doca_mmap_populate
This operation adds memory range to a local DOCA memory map.

If there are devices attached to the doca_mmap, the function performs memory registration of the new memory range added with each of those devices.

doca_error_t doca_mmap_populate(struct doca_mmap *mmap, char *addr, size_t len, size_t pg_sz, doca_mmap_memrange_free_cb_t *free_cb, void *opaque);
Where:
mmap – DOCA memory map structure
addr – the address in which the memory range begins
len – the length of the memory range in bytes
pg_sz – page size alignment of the provided memory range
free_cb – callback function to free the populated memory range on doca_mmap_destroy()
opaque – opaque value to be passed to free_cb once called
4.7.10. doca_mmap_export
This operation composes a DOCA memory map representation as a memory export descriptor for later import with doca_mmap_create_from_export() for one of the previously added devices to the memory map.

This function allows access to specific host memory ranges registered to the mmap from the DPU.

Once this function is called on an object, it is considered exported.

Freeing the memory buffer marked with *export is the caller's responsibility.

This operation is not permitted for:
Un-started/stopped memory map object
Memory map object that has been exported or created from export
doca_error_t doca_mmap_export(struct doca_mmap *mmap, const struct doca_dev *dev, uint8_t **export_desc, size_t *export_desc_len);
Where:
mmap – DOCA memory map structure
dev – DOCA device previously added to the memory map via doca_mmap_dev_add()
export_desc – on success, return should have a pointer to the allocated export descriptor representing the memory map object for the device provided as dev (output parameter)
export_desc_len – length in bytes of the export_desc parameter (output parameter)
Note: Only a doca_mmap consisting of a single chunk is supported.
4.7.11. doca_mmap_create_from_export
This operation creates a DOCA memory map object representing memory ranges in remote system memory space.
Note: The created object is not backed by local memory.
This function allows access to specific host memory ranges registered to the mmap from the DPU.

Once this function is called on an object, it is considered as from_export.

doca_error_t doca_mmap_create_from_export(const char *name, const uint8_t *export_desc, size_t export_desc_len, struct doca_dev *dev, struct doca_mmap **mmap);
Where:
name – name of newly created DOCA memory map
export_desc – the export descriptor generated by doca_mmap_export
export_desc_len – length in bytes of the export_desc parameter
dev – a local device connected to the device that resides in the exported mmap
mmap – DOCA memory map granting access to remote memory (output parameter)
Note: Only a doca_mmap consisting of a single chunk is supported.
Note: The name given by the user does not play a role, implementation-wise.

4.7.9。 doca_mmap_populate
此操作将内存范围添加到本地 DOCA 内存映射。

如果有设备附加到 doca_mmap，该函数将对每个设备添加的新内存范围执行内存注册。

doca_error_t doca_mmap_populate(struct doca_mmap *mmap, char *addr, size_t len, size_t pg_sz, doca_mmap_memrange_free_cb_t *free_cb, void *opaque);
在哪里：
mmap——DOCA内存映射结构
addr – 内存范围开始的地址
len – 内存范围的长度（以字节为单位）
pg_sz – 提供的内存范围的页面大小对齐
free_cb – 用于释放 doca_mmap_destroy() 上填充的内存范围的回调函数
opaque – 调用后传递给 free_cb 的不透明值
4.7.10. doca_mmap_export
此操作将 DOCA 内存映射表示形式组成为内存导出描述符，以便稍后使用 doca_mmap_create_from_export() 将先前添加到内存映射的设备之一导入。

此函数允许从 DPU 访问注册到 mmap 的特定主机内存范围。

一旦在对象上调用此函数，它就被视为导出。

释放标有 *export 的内存缓冲区是调用者的责任。

不允许执行此操作：
未启动/停止的内存映射对象
已导出或通过导出创建的内存映射对象
doca_error_t doca_mmap_export(struct doca_mmap *mmap, const struct doca_dev *dev, uint8_t **export_desc, size_t *export_desc_len);
在哪里：
mmap——DOCA内存映射结构
dev – DOCA 设备先前通过 doca_mmap_dev_add() 添加到内存映射
export_desc – 成功时，返回应该有一个指向分配的导出描述符的指针，该描述符表示作为 dev （输出参数）提供的设备的内存映射对象
export_desc_len –export_desc 参数（输出参数）的长度（以字节为单位）
注意：仅支持由单个块组成的 doca_mmap。
4.7.11. doca_mmap_create_from_export
此操作创建一个 DOCA 内存映射对象，表示远程系统内存空间中的内存范围。
注意：创建的对象不受本地内存支持。
此函数允许从 DPU 访问注册到 mmap 的特定主机内存范围。

一旦在对象上调用此函数，它就被视为 from_export。

doca_error_t doca_mmap_create_from_export(const char *name, const uint8_t *export_desc, size_t export_desc_len, struct doca_dev *dev, struct doca_mmap **mmap);
在哪里：
name – 新创建的 DOCA 内存映射的名称
export_desc – doca_mmap_export 生成的导出描述符
export_desc_len –export_desc 参数的长度（以字节为单位）
dev – 连接到驻留在导出的 mmap 中的设备的本地设备
mmap – DOCA 内存映射，授予对远程内存的访问权限（输出参数）
注意：仅支持由单个块组成的 doca_mmap。
注意：用户给出的名称在实现方面不起作用。

4.8. doca_ctx
Note: All doca_ctx operations are considered thread-safe.
The DOCA Context structure holds configurations for the execution of data-processing jobs. DOCA libraries that want to expose data-path jobs can implement the DOCA Context interface.

DOCA CTX provides a common interface for configuring and starting said libraries.

Devices can be provided to libraries using doca_ctx_dev_add(). Other configurations can be provided using a library-specific API. Once all configurations are provided, the library can be started using doca_ctx_start(). Once a library has been created, it starts accepting one or more DOCA WorkQ through doca_ctx_workq_add(). The WorkQ can then be used for submitting jobs, progressing jobs, and polling events.

The following operations become possible only after starting the DOCA Context:

Adding WorkQ to CTX using doca_ctx_workq_add()
Removing WorkQ from CTX using doca_ctx_workq_rm()
Submitting a job using doca_workq_submit()
The following are not possible after start and become possible again after calling doca_ctx_stop:
Adding device to CTX using doca_ctx_dev_add()
Removing device from CTX using doca_ctx_dev_rm()
Note: A doca_ctx cannot be created by itself. Instead, you need to create a library instance (e.g., doca_dma_create()). Then you can acquire a CTX by converting that to a doca_ctx (e.g., doca_dma_as_ctx()).
4.8.1. doca_ctx_dev_add
This operation is a common interface for providing a device to a library.

Each library expects different capabilities and properties to exist for the device. If the provided device does not meet the requirements, it is rejected, causing it to fail.

Each successfully added device must be removed before destroying the CTX.

doca_error_t doca_ctx_dev_add(struct doca_ctx *ctx, struct doca_dev *dev);
Where:
ctx – a DOCA Context, representing a data-path library instance
dev – a DOCA Device with required capabilities
Note: This function cannot be used after CTX is started (doca_ctx_start()). CTX must be stopped (doca_ctx_stop()) to use it again.
4.8.2. doca_ctx_dev_rm
This operation is a common interface for removing a device from a library.

Devices must be removed from a context after stopping it and before destroying it.

doca_error_t doca_ctx_dev_rm(struct doca_ctx *ctx, struct doca_dev *dev);
Where:
ctx – a DOCA Context, representing a data-path library instance
dev – same DOCA Device that was previously provided through doca_ctx_dev_add()
Note: This function cannot be used after CTX is started (doca_ctx_start()). CTX must be stopped (doca_ctx_stop()) to use it again.
4.8.3. doca_ctx_start
This operation is a common interface for starting a library instance. First, provide all configurations to the library and then call start.

Once a CTX has been started the following operations become possible:
Adding WorkQ to CTX using doca_ctx_workq_add()
Removing WorkQ from CTX using doca_ctx_workq_rm()
Submitting a job related to this CTX using doca_workq_submit()
Whereas the following operations no longer stay possible:
Adding device to CTX using doca_ctx_dev_add()
Removing a device from CTX using doca_ctx_dev_rm()
To re-enable them, call doca_ctx_stop().

doca_error_t doca_ctx_start(struct doca_ctx *ctx);
Where:
ctx – a DOCA Context, representing a data-path library instance
4.8.4. doca_ctx_stop
This operation is a common interface for stopping a library instance. This can be done to provide further configurations to the library after starting it.

For a list of allowed operations after stop/start, refer to doca_ctx_start().

doca_error_t doca_ctx_stop(struct doca_ctx *ctx);
Where:
ctx – a DOCA Context, representing a data-path library instance
4.8.5. doca_ctx_workq_add
This operation is a common interface for providing a WorkQ to a library.

For a library to start accepting and processing jobs, it must first have WorkQ attached to it so that jobs can be submitted to this WorkQ, and so the WorkQ can be polled to retrieve job completions and/or events.

Each successfully added WorkQ must be removed before stopping the CTX.

doca_error_t doca_ctx_workq_add(struct doca_ctx *ctx, struct doca_workq *workq);
Where:
ctx – a DOCA Context, representing a data-path library instance
workq – DOCA WorkQ for job handling
Note: This function can only be used after CTX is started (doca_ctx_start()). The user must remove all WorkQs before stopping CTX (doca_ctx_stop()).
4.8.6. doca_ctx_workq_rm
This operation is a common interface for removing a WorkQ from a library.

Added WorkQs must be removed before stopping a CTX using this API.

To remove a WorkQ, the user's responsibility is to ensure that no inflight jobs are pending completion.

doca_error_t doca_ctx_workq_rm(struct doca_ctx *ctx, struct doca_workq *workq);
Where:
ctx – a DOCA Context, representing a data-path library instance
workq – same DOCA WorkQ previously provided to doca_ctx_workq_add()
Note: This function can only be used after CTX is started (doca_ctx_start()). The user must remove all WorkQs before stopping CTX (doca_ctx_stop()).

4.8. 多卡_ctx
注意：所有 doca_ctx 操作都被认为是线程安全的。
DOCA 上下文结构保存用于执行数据处理作业的配置。想要公开数据路径作业的 DOCA 库可以实现 DOCA Context 接口。

DOCA CTX 提供了一个用于配置和启动所述库的通用接口。

可以使用 doca_ctx_dev_add() 将设备提供给库。可以使用特定于库的 API 来提供其他配置。提供所有配置后，可以使用 doca_ctx_start() 启动该库。创建库后，它开始通过 doca_ctx_workq_add() 接受一个或多个 DOCA WorkQ。然后，WorkQ 可用于提交作业、处理作业和轮询事件。

只有启动 DOCA Context 后才能进行以下操作：

使用 doca_ctx_workq_add() 将 WorkQ 添加到 CTX
使用 doca_ctx_workq_rm() 从 CTX 中删除 WorkQ
使用 doca_workq_submit() 提交作业
以下情况在启动后不可能，但在调用 doca_ctx_stop 后又变得可能：
使用 doca_ctx_dev_add() 将设备添加到 CTX
使用 doca_ctx_dev_rm() 从 CTX 中删除设备
注意：doca_ctx 不能自行创建。相反，您需要创建一个库实例（例如 doca_dma_create()）。然后，您可以通过将其转换为 doca_ctx（例如 doca_dma_as_ctx()）来获取 CTX。
4.8.1. doca_ctx_dev_add
此操作是向库提供设备的通用接口。

每个库都期望设备具有不同的功能和属性。如果提供的设备不符合要求，则会被拒绝，导致失败。

在销毁 CTX 之前，必须删除每个成功添加的设备。

doca_error_t doca_ctx_dev_add(结构 doca_ctx *ctx, 结构 doca_dev *dev);
在哪里：
ctx – DOCA 上下文，表示数据路径库实例
dev – 具有所需功能的 DOCA 设备
注意：CTX 启动（doca_ctx_start()）后，该函数无法使用。必须停止 CTX (doca_ctx_stop()) 才能再次使用它。
4.8.2. doca_ctx_dev_rm
此操作是用于从库中删除设备的通用接口。

在停止上下文之后和销毁上下文之前，必须将设备从上下文中删除。

doca_error_t doca_ctx_dev_rm(结构 doca_ctx *ctx, 结构 doca_dev *dev);
在哪里：
ctx – DOCA 上下文，表示数据路径库实例
dev – 之前通过 doca_ctx_dev_add() 提供的相同 DOCA 设备
注意：CTX 启动（doca_ctx_start()）后，该函数无法使用。必须停止 CTX (doca_ctx_stop()) 才能再次使用它。
4.8.3. doca_ctx_start
该操作是启动库实例的通用接口。首先，向库提供所有配置，然后调用 start。

一旦 CTX 启动，就可以进行以下操作：
使用 doca_ctx_workq_add() 将 WorkQ 添加到 CTX
使用 doca_ctx_workq_rm() 从 CTX 中删除 WorkQ
使用 doca_workq_submit() 提交与此 CTX 相关的作业
然而以下操作不再可能：
使用 doca_ctx_dev_add() 将设备添加到 CTX
使用 doca_ctx_dev_rm() 从 CTX 中删除设备
要重新启用它们，请调用 doca_ctx_stop()。

doca_error_t doca_ctx_start(struct doca_ctx *ctx);
在哪里：
ctx – DOCA 上下文，表示数据路径库实例
4.8.4. doca_ctx_stop
此操作是用于停止库实例的通用接口。这样做可以在启动库后为库提供进一步的配置。

有关停止/启动后允许的操作列表，请参阅 doca_ctx_start()。

doca_error_t doca_ctx_stop(struct doca_ctx *ctx);
在哪里：
ctx – DOCA 上下文，表示数据路径库实例
4.8.5。 doca_ctx_workq_add
此操作是向图书馆提供 WorkQ 的通用接口。

对于要开始接受和处理作业的库，它必须首先附加 WorkQ，以便可以将作业提交到此 WorkQ，然后可以轮询 WorkQ 以检索作业完成情况和/或事件。

在停止 CTX 之前，必须删除每个成功添加的 WorkQ。

doca_error_t doca_ctx_workq_add(结构 doca_ctx *ctx, 结构 doca_workq *workq);
在哪里：
ctx – DOCA 上下文，表示数据路径库实例
workq – 用于作业处理的 DOCA WorkQ
注意：该函数只能在CTX启动（doca_ctx_start()）后使用。用户必须在停止 CTX (doca_ctx_stop()) 之前删除所有 WorkQ。
4.8.6。 doca_ctx_workq_rm
此操作是用于从库中删除 WorkQ 的通用接口。

在使用此 API 停止 CTX 之前，必须删除添加的 WorkQ。

要删除 WorkQ，用户的责任是确保没有正在进行的作业等待完成。

doca_error_t doca_ctx_workq_rm(结构 doca_ctx *ctx, 结构 doca_workq *workq);
在哪里：
ctx – DOCA 上下文，表示数据路径库实例
workq – 之前提供给 doca_ctx_workq_add() 的相同 DOCA WorkQ
注意：该函数只能在CTX启动（doca_ctx_start()）后使用。用户必须删除所有 WorkQ

4.9. doca_workq
Note: All doca_workq operations are considered thread-unsafe.
The DOCA WorkQ structure holds execution resources that different DOCA contexts can utilize, where the WorkQ provides a common interface for submitting a job, progressing a job until completion, and polling events.

The same WorkQ can be provided to multiple different CTXs, creating a single place for submitting jobs to any CTX and eventually receiving their results.

Jobs can be submitted using doca_workq_submit(). They can then be progressed using doca_workq_progress_retrieve(). Once the job is completed, a job completion event is received from the method.

In addition to jobs, some contexts expose events that can be polled using doca_workq_progress_retrieve().

4.9.1. doca_workq_create
This operation creates a DOCA WorkQ instance, with a set depth. The depth defines the maximum number of in-flight jobs allowed on this WorkQ.

Once a WorkQ is created, it can be passed to multiple CTXs using doca_ctx_workq_add(), allowing job submission and retrieval of events.

Each successfully created WorkQ must be destroyed using doca_workq_destroy().

doca_error_t doca_workq_create(uint32_t depth, struct doca_workq **workq);
Where:
depth – the depth of the WorkQ. This can also be set using the property setter.
workq – holds the newly created WorkQ (output parameter)
4.9.2. doca_workq_destroy
This operation destroys a DOCA WorkQ instance.

Before destroying a WorkQ, it must be removed from all the CTXs that are using it via doca_ctx_workq_rm().

doca_error_t doca_workq_destroy(struct doca_workq *workq);
Where:
workq – a DOCA WorkQ created via doca_workq_create()
4.9.3. doca_workq_property_set
This operation sets the value of a DOCA WorkQ property. It returns an error if the operation is not successful.

doca_error_t doca_workq_property_set(struct doca_workq *workq, enum doca_workq_property property, const uint8_t *value, uint32_t size);
Where:
workq – DOCA WorkQ structure whose property to change
property – the property to set. See enum doca_workq_property.
value – the new value of the property
size – the size of the property in bytes
4.9.4. doca_workq_property_get
This operation gets the up-to-date value of a DOCA WorkQ property. It returns an error if the operation is not successful.

doca_error_t doca_workq_property_get(const struct doca_workq *workq, enum doca_workq_property property, uint8_t *value, uint32_t size);
Where:
workq – DOCA WorkQ structure whose property to return
property – the property to get. See enum doca_workq_property.
value – the value of the property (output parameter)
size – the size of the property in bytes
4.9.5. doca_workq_submit
This is a common interface for submitting a job to a library.

To submit a job, a library job must be built first. Each library that implements a DOCA Context exposes several jobs in its header.

These jobs can be submitted to the library using the CTX of that library.

The WorkQ must have been previously added to a CTX that can handle the job.

For the job to complete, doca_workq_progress_retrieve() must be called until it succeeds and returns the job result.

doca_error_t doca_workq_submit(struct doca_workq *workq, struct doca_job const *job);
Where:
workq – DOCA WorkQ previously added to a CTX that can handle the provided job
job – base of a job defined by a library implementing DOCA CTX. The job also holds a pointer to the CTX that handles the job. Both must be compatible.
4.9.6. doca_workq_progress_retrieve
This is a common interface for polling of events.

This is a polling method that can be used to wait for events.

Events can be categorized to two types:
Job completion events – can only be received as a result of a submitted job
External events – can always be received based on events exposed by associated CTXs
Each CTX exposes jobs and events. Submitting a job using doca_workq_submit() eventually returns a job completion event using doca_workq_progress_retrieve().

Other events can always be received based on the documentation of the library implementing CTX.

Calling doca_workq_progress_retrieve() progresses all jobs but in no particular order. Events are returned as soon as an they occur, regardless of the order in which they are submitted.

doca_error_t doca_workq_progress_retrieve(struct doca_workq *workq, struct doca_event *ev, int flags);
Where:
workq – DOCA WorkQ previously added to a CTX that can handle the provided job
ev – holds the retrieved event (output parameter valid only if the method returns DOCA_SUCCESS)
flags – a combination of enum doca_workq_retrieve_flags

4.9. doca_workq
注意：所有 doca_workq 操作都被视为线程不安全。
DOCA WorkQ 结构保存不同 DOCA 上下文可以使用的执行资源，其中 WorkQ 提供用于提交作业、推进作业直至完成以及轮询事件的公共接口。

可以向多个不同的 CTX 提供相同的 WorkQ，从而创建一个用于向任何 CTX 提交作业并最终接收其结果的单一位置。

可以使用 doca_workq_submit() 提交作业。然后可以使用 doca_workq_progress_retrieve() 进行处理。一旦作业完成，就会从该方法接收作业完成事件。

除了作业之外，某些上下文还公开可以使用 doca_workq_progress_retrieve() 进行轮询的事件。

4.9.1. doca_workq_创建
此操作创建一个具有设定深度的 DOCA WorkQ 实例。深度定义了此 WorkQ 上允许的最大正在进行的作业数。

创建 WorkQ 后，可以使用 doca_ctx_workq_add() 将其传递到多个 CTX，从而允许作业提交和事件检索。

每个成功创建的 WorkQ 必须使用 doca_workq_destroy() 销毁。

doca_error_t doca_workq_create(uint32_t 深度, 结构 doca_workq **workq);
在哪里：
深度 – WorkQ 的深度。也可以使用属性设置器来设置。
workq – 保存新创建的WorkQ（输出参数）
4.9.2. doca_workq_destroy
此操作会销毁 DOCA WorkQ 实例。

在销毁 WorkQ 之前，必须通过 doca_ctx_workq_rm() 从所有正在使用它的 CTX 中将其删除。

doca_error_t doca_workq_destroy(struct doca_workq *workq);
在哪里：
workq – 通过 doca_workq_create() 创建的 DOCA WorkQ
4.9.3. doca_workq_property_set
此操作设置 DOCA WorkQ 属性的值。如果操作不成功，它会返回错误。

doca_error_t doca_workq_property_set(struct doca_workq *workq, enum doca_workq_property property, const uint8_t *value, uint32_t size);
在哪里：
workq – DOCA WorkQ 结构，其属性要更改
property – 要设置的属性。请参阅枚举 doca_workq_property。
value – 财产的新价值
size – 属性的大小（以字节为单位）
4.9.4. doca_workq_property_get
此操作获取 DOCA WorkQ 属性的最新值。如果操作不成功，它会返回错误。

doca_error_t doca_workq_property_get(const struct doca_workq *workq, enum doca_workq_property 属性, uint8_t *value, uint32_t 大小);
在哪里：
workq – DOCA WorkQ 结构，其属性返回
财产——要获得的财产。请参阅枚举 doca_workq_property。
value – 属性的值（输出参数）
size – 属性的大小（以字节为单位）
4.9.5。 doca_workq_提交
这是向图书馆提交作业的通用接口。

要提交作业，必须首先构建库作业。每个实现 DOCA Context 的库都会在其标头中公开多个作业。

可以使用该库的 CTX 将这些作业提交到该库。

WorkQ 必须事先添加到可以处理该作业的 CTX 中。

为了完成作业，必须调用 doca_workq_progress_retrieve() 直到成功并返回作业结果。

doca_error_t doca_workq_submit(struct doca_workq *workq, struct doca_job const *job);
在哪里：
workq – DOCA WorkQ 之前添加到可以处理所提供作业的 CTX
job – 由实现 DOCA CTX 的库定义的作业基础。该作业还保存一个指向处理该作业的 CTX 的指针。两者必须兼容。
4.9.6。 doca_workq_progress_retrieve
这是轮询事件的通用接口。

这是一种轮询方法，可用于等待事件。

事件可以分为两类：
作业完成事件 – 只能作为提交作业的结果而接收
外部事件 – 始终可以根据关联 CTX 公开的事件接收
每个 CTX 都会公开作业和事件。使用 doca_workq_submit() 提交作业最终会使用 doca_workq_progress_retrieve() 返回作业完成事件。

根据实现 CTX 的库的文档，始终可以接收其他事件。

调用 doca_workq_progress_retrieve() 会处理所有作业，但没有特定的顺序。事件一旦发生就会立即返回，无论它们的提交顺序如何。

doca_error_t doca_workq_progress_retrieve(struct doca_workq *workq, struct doca_event *ev, int flags);
在哪里：
workq – DOCA WorkQ 之前添加到可以处理所提供作业的 CTX
ev – 保存检索到的事件（仅当方法返回 DOCA_SUCCESS 时输出参数才有效）
flags – 枚举 doca_workq_retrieve_flags 的组合

5. Object Life Cycle
5.1. Device Life Cycle
Locate all local devices accessible by your system with doca_devinfo_list_create().
Locate all remote devices accessible by a given local device with doca_devinfo_remote_list_create().
At all times you can find out the properties of the device using doca_devinfo_property_get() or doca_devinfo_remote_property_get().
Initialize the devices with doca_dev_open() or doca_dev_remote_open(), accordingly. Once opened, a doca_dev or doca_dev_remote is returned by the operation representing a running device. This structure serves as a handle to the underlying hardware and allocates and manages the device resources. Note that if a local device has already been opened, the same doca_dev is returned. At all times, the doca_devinfo structure can be accessed from doca_dev or doca_dev_remote with doca_dev_as_devinfo() or doca_dev_remote_as_devinfo() , respectively.
It is the user’s responsibility to free the list of device/remote device information using doca_devinfo_list_destroy() or doca_devinfo_remote_list_destroy() at the end. At any point, the user can free an open device by using doca_dev_close() or doca_dev_remote_close().
A remote device information list stays valid even after closing the doca_dev instance used to acquire it.
5.2. Buffer Life Cycle
Create a buffer with the buffer inventory API by following these instructions:
Retrieve a buffer from the inventory pointing to a certain memory region on a given mmap with doca_buf_inventory_buf_by_addr()
You may duplicate a buffer using doca_buf_inventory_buf_dup(). The duplicated buffer is retrieved from the inventory provided.
Note: The buffer extensions are set upon the creation of the inventory by the user.
To retrieve the doca_buf address and len, use doca_buf_head_get() and doca_buf_len_get(), respectively.
To return the buffer back to the buffer inventory, use doca_buf_refcount_rm()
5.3. Buffer Inventory Life Cycle
Create a buffer inventory with doca_buf_inventory_create().
View the default/current properties of the buffer inventory using doca_buf_inventory_property_get(). You may change the inventory properties to suit your needs with doca_buf_inventory_property_set().
Enable the retrieval of buffers from the buffer by calling doca_buf_inventory_start(). Notice that on the first call to doca_buf_inventory_start(), the inventory properties become read-only and can no longer be changed.
At any point, doca_buf_inventory_stop() can be called to prevent new buffers from being retrieved from the inventory until doca_buf_inventory_start() is called once again.
It is the user's responsibility to free the buffer inventory using doca_buf_inventory_destroy() at the end. Notice that all allocated buffers must be returned to the inventory before calling this operation for it to succeed.
5.4. Memory Map Life Cycle
Create an mmap to hold relevant memory ranges and details regarding the devices associated with those ranges using doca_mmap_create().
View the default/current properties of mmap using doca_mmap_property_get(). You may change the properties to suit your needs via doca_mmap_property_set().
Enable mapping of buffers to the memory regions, add/remove devices, and populate the mmap by calling doca_mmap_start(). Note that on the first call to doca_mmap_start(), the mmap properties become read-only and can no longer be changed.
The mmap is initialized without any memory ranges. The user can add a memory range to the mmap using doca_mmap_populate().
Associate different devices with the memory ranges held by the mmap by calling doca_mmap_dev_add() and disassociate a device added previously using doca_mmap_dev_rm(). Note that the order in which doca_mmap_populate() and doca_mmap_dev_add() are called is interchangeable and does not affect the process of associating the memory regions and the devices to one another.
At any point, doca_mmap_stop() can be called to prevent the mmap from changing until doca_mmap_start() is called once again. When the mmap is stopped, no memory range or device can be added to the mmap, and the mmap cannot be exported. Moreover, when the mmap stops the creation of buffers, pointing to a memory region in said mmap is disabled.
The mmap can be exported from the host to the BlueField by calling doca_mmap_export() from the host and recreating the mmap by calling doca_mmap_create_from_export() from the BlueField. For more information on executing these operations, see section Exporting and Recreating Memory Map Object from Export.
It is the user's responsibility to free the mmap using doca_mmap_destroy() at the end. The mmap cannot be released as long as there are buffers pointing to memory regions in the mmap. Hence those buffers must be freed first.
5.5. Context Map Life Cycle
Create library context by using the library's create method doca_T_create() (e.g., doca_dma_create()).
Obtain a DOCA CTX by converting the library context into a DOCA CTX using the library's convert method, doca_T_as_ctx() (e.g., doca_dma_as_ctx()). Now the library context and the DOCA CTX are the same, any modification that is done automatically applies to both instances.
Add a required device to the CTX using doca_ctx_dev_add(). The device must be compatible with the library. This can be verified using the library's query capabilities API, doca_T_devinfo_caps_get() (e.g., doca_dma_devinfo_caps_get()).
After adding the required device, the CTX can be started using doca_ctx_start().
Only After the CTX has been started, WorkQs can be added to it using doca_ctx_workq_add(). The WorkQ represents a single thread's handle to the CTX for submission and polling of jobs.
After adding a WorkQ to a CTX, it can start accepting jobs defined in the library's header file (e.g., struct doca_dma_job_memcpy).
Refer to the library's documentation to find if multiple WorkQs can be attached to the same CTX, or if each WorkQ requires an exclusive CTX.
After all jobs submitted to the CTX through a WorkQ are done, the WorkQ can be removed using doca_ctx_workq_rm().
The CTX can be stopped using doca_ctx_stop() only after removing all WorkQs from it.
After stopping the CTX, any previously added devices must be removed using doca_ctx_dev_rm().
After removing all WorkQs and devices, it becomes possible to destroy the CTX using the library destroy method doca_T_destroy() (e.g., doca_dma_destroy()) while using the library context as reference.
Note: The CTX must not be destroyed if any resources (i.e., device, WorkQ, job...) are still attached to it.
5.6. Work Queue Life Cycle
Create a WorkQ using doca_workq_create(), providing the depth property.
A WorkQ can be used to submit and progress jobs from a single thread only. As such, it is only appropriate to create one WorkQ per thread in a multi-threaded application.
Add a WorkQ to a started CTX using doca_ctx_workq_add(). Multiple WorkQs can be attached to the same CTX based on the API library's CTX documentation.
The same WorkQ can be added to multiple CTXs, of any type. This allows out of order progression of jobs from multiple CTXs.
After adding a WorkQ to a CTX, use doca_workq_submit() to submit jobs to the library. The job should reference the same CTX that holds the WorkQ.
Refer to the library CTX's header (e.g., doca_dma.h) to find jobs that can be submitted to the CTX through the WorkQ.
Submitted jobs should be progressed until completion using the method doca_workq_progress_retrieve().
A submitted job should remain valid until a matching job completion event has been received from doca_workq_progress_retrieve().
Once there are no more pending jobs in the WorkQ intended for a CTX, it can be removed from that CTX using doca_ctx_workq_rm().
After removing the WorkQ from all CTXs, it can be destroyed using doca_workq_destroy().
Only if a WorkQ is not currently added to any CTX then the property setter doca_workq_property_set() can be called.
The properties of the WorkQ can be queried at all times using doca_workq_property_get().

5. 对象生命周期
5.1. 设备生命周期
使用 doca_devinfo_list_create() 找到系统可访问的所有本地设备。
使用 doca_devinfo_remote_list_create() 查找给定本地设备可访问的所有远程设备。
您随时可以使用 doca_devinfo_property_get() 或 doca_devinfo_remote_property_get() 找出设备的属性。
相应地使用 doca_dev_open() 或 doca_dev_remote_open() 初始化设备。打开后，代表正在运行的设备的操作将返回 doca_dev 或 doca_dev_remote。该结构充当底层硬件的句柄，并分配和管理设备资源。请注意，如果本地设备已打开，则返回相同的 doca_dev。在任何时候，都可以分别使用 doca_dev_as_devinfo() 或 doca_dev_remote_as_devinfo() 从 doca_dev 或 doca_dev_remote 访问 doca_devinfo 结构。
用户有责任在最后使用 doca_devinfo_list_destroy() 或 doca_devinfo_remote_list_destroy() 释放设备/远程设备信息列表。在任何时候，用户都可以使用 doca_dev_close() 或 doca_dev_remote_close() 释放打开的设备。
即使关闭用于获取远程设备信息列表的 doca_dev 实例，远程设备信息列表仍然有效。
5.2. 缓冲区生命周期
按照以下说明使用缓冲区库存 API 创建缓冲区：
使用 doca_buf_inventory_buf_by_addr() 从清单中检索指向给定 mmap 上特定内存区域的缓冲区
您可以使用 doca_buf_inventory_buf_dup() 复制缓冲区。复制的缓冲区是从提供的清单中检索的。
注意：缓冲区扩展是在用户创建清单时设置的。
要检索 doca_buf 地址和 len，请分别使用 doca_buf_head_get() 和 doca_buf_len_get()。
要将缓冲区返回到缓冲区库存，请使用 doca_buf_refcount_rm()
5.3. 缓冲区库存生命周期
使用 doca_buf_inventory_create() 创建缓冲区清单。
使用 doca_buf_inventory_property_get() 查看缓冲区清单的默认/当前属性。您可以使用 doca_buf_inventory_property_set() 更改库存属性以满足您的需求。
通过调用 doca_buf_inventory_start() 启用从缓冲区检索缓冲区。请注意，第一次调用 doca_buf_inventory_start() 时，库存属性将变为只读且无法再更改。
在任何时候，都可以调用 doca_buf_inventory_stop() 以防止从清单中检索新缓冲区，直到再次调用 doca_buf_inventory_start() 为止。
用户有责任在最后使用 doca_buf_inventory_destroy() 释放缓冲区库存。请注意，在调用此操作才能成功之前，必须将所有分配的缓冲区返回到清单中。

5.4. 内存映射生命周期
使用 doca_mmap_create() 创建一个 mmap 来保存相关内存范围以及与这些范围关联的设备的详细信息。
使用 doca_mmap_property_get() 查看 mmap 的默认/当前属性。您可以通过 doca_mmap_property_set() 更改属性以满足您的需要。
启用缓冲区到内存区域的映射、添加/删除设备以及通过调用 doca_mmap_start() 填充 mmap。请注意，第一次调用 doca_mmap_start() 时，mmap 属性将变为只读且无法再更改。
mmap 初始化时没有任何内存范围。用户可以使用 doca_mmap_populate() 将内存范围添加到 mmap。
通过调用 doca_mmap_dev_add() 将不同的设备与 mmap 保存的内存范围关联起来，并使用 doca_mmap_dev_rm() 取消先前添加的设备的关联。请注意，调用 doca_mmap_populate() 和 doca_mmap_dev_add() 的顺序是可以互换的，并且不会影响将内存区域和设备相互关联的过程。
在任何时候，都可以调用 doca_mmap_stop() 以防止 mmap 发生更改，直到再次调用 doca_mmap_start()。当mmap停止时，不能向mmap添加任何内存范围或设备，并且不能导出mmap。此外，当mmap停止创建缓冲区时，指向所述mmap中的存储器区域被禁用。
通过从主机调用 doca_mmap_export() 并通过从 BlueField 调用 doca_mmap_create_from_export() 重新创建 mmap，可以将 mmap 从主机导出到 BlueField。有关执行这些操作的更多信息，请参阅通过 Export 导出和重新创建内存映射对象部分。
用户有责任在最后使用 doca_mmap_destroy() 释放 mmap。只要 mmap 中存在指向内存区域的缓冲区，就无法释放 mmap。因此，必须首先释放这些缓冲区。
5.5. 上下文映射生命周期
使用库的创建方法 doca_T_create()（例如 doca_dma_create()）创建库上下文。
通过使用库的转换方法 doca_T_as_ctx()（例如 doca_dma_as_ctx()）将库上下文转换为 DOCA CTX 来获取 DOCA CTX。现在，库上下文和 DOCA CTX 是相同的，自动完成的任何修改都适用于两个实例。
使用 doca_ctx_dev_add() 将所需设备添加到 CTX。该设备必须与库兼容。这可以使用库的查询功能 API doca_T_devinfo_caps_get()（例如 doca_dma_devinfo_caps_get()）进行验证。
添加所需设备后，可以使用 doca_ctx_start() 启动 CTX。
只有在 CTX 启动后，才能使用 doca_ctx_workq_add() 将 WorkQ 添加到其中。 WorkQ 代表 CTX 的单个线程句柄，用于提交和轮询作业。
将 WorkQ 添加到 CTX 后，它可以开始接受库头文件（例如 struct doca_dma_job_memcpy）中定义的作业。
请参阅库的文档，了解是否可以将多个 WorkQ 连接到同一个 CTX，或者每个 WorkQ 是否需要独占 CTX。
通过 WorkQ 提交到 CTX 的所有作业完成后，可以使用 doca_ctx_workq_rm() 删除 WorkQ。
仅在从中删除所有 WorkQ 后，才能使用 doca_ctx_stop() 停止 CTX。
停止 CTX 后，必须使用 doca_ctx_dev_rm() 删除任何先前添加的设备。
删除所有 WorkQ 和设备后，可以使用库销毁方法 doca_T_destroy()（例如 doca_dma_destroy()）销毁 CTX，同时使用库上下文作为参考。
注意：如果仍有任何资源（即设备、WorkQ、作业...）附加到 CTX，则不得销毁 CTX。

5.6. 工作队列生命周期
使用 doca_workq_create() 创建 WorkQ，并提供深度属性。
WorkQ 只能用于从单个线程提交和处理作业。因此，在多线程应用程序中，只适合为每个线程创建一个 WorkQ。
使用 doca_ctx_workq_add() 将 WorkQ 添加到启动的 CTX。根据 API 库的 CTX 文档，多个 WorkQ 可以附加到同一个 CTX。
相同的 WorkQ 可以添加到任何类型的多个 CTX。这允许来自多个 CTX 的作业无序进展。
将 WorkQ 添加到 CTX 后，使用 doca_workq_submit() 将作业提交到库。该作业应引用保存 WorkQ 的同一 CTX。
请参阅库 CTX 的标头（例如，doca_dma.h）以查找可以通过 WorkQ 提交到 CTX 的作业。
提交的作业应使用 doca_workq_progress_retrieve() 方法进行处理直至完成。
提交的作业应保持有效，直到从 doca_workq_progress_retrieve() 收到匹配的作业完成事件。
一旦 WorkQ 中不再有用于 CTX 的待处理作业，就可以使用 doca_ctx_workq_rm() 将其从该 CTX 中删除。
从所有 CTX 中删除 WorkQ 后，可以使用 doca_workq_destroy() 销毁它。
仅当 WorkQ 当前未添加到任何 CTX 时，才可以调用属性设置器 doca_workq_property_set()。
可以随时使用 doca_workq_property_get() 查询 WorkQ 的属性。

此操作根据远程设备的信息创建远程设备。

打开远程设备会激活其资源并准备好供 DOCA 中的不同库使用。

一旦不再需要设备，就应该将其关闭。

返回的远程设备信息与用于打开该设备的信息具有相同的属性。

4.5. doca_buf
Note: All doca_buf operations are considered thread-unsafe.
The DOCA Buffer structure is a descriptor that holds information on a memory region, defined by the address in which the memory region begins, and the length of the memory region in bytes. The address and length of the memory region are set when the buffer is created. They then become read-only.

4.5.1. doca_buf_head_get
This operation returns the address of the memory region that the buffer points to.

doca_error_t doca_buf_head_get(struct doca_buf *buf, uint8_t **head);
Where:
buf – the DOCA Buffer structure
head – the address of the memory region that the buffer points to (output parameter)
4.5.2. doca_buf_len_get
This operation returns the size of the memory region pointed by the buffer in bytes.

doca_error_t doca_buf_len_get(struct doca_buf *buf, size_t *len);
Where:
buf – the DOCA Buffer structure
len – the length of the memory region pointed by the buffer (output parameter)
4.5.3. doca_buf_refcount_rm
This operation decreases doca_buf reference count. Once it reaches zero, the function destroys the doca_buf object.

doca_error_t doca_buf_refcount_rm(struct doca_buf *buf, uint16_t *refcount);
Where:
buf – the DOCA Buffer structure
refcount – the doca_buf reference count value before this operation took place (output parameter)
4.5.4. doca_buf_refcount_get
This operation returns doca_buf reference count value.

doca_error_t doca_buf_refcount_get(struct doca_buf *buf, uint16_t *refcount);
Where:
buf – the DOCA Buffer structure
refcount – the doca_buf reference count value (output parameter)

4.5. DOCA缓冲区
注意：所有 doca_buf 操作都被认为是线程不安全的。
DOCA Buffer 结构是一个描述符，保存有关内存区域的信息，由内存区域开始的地址以及内存区域的长度（以字节为单位）定义。内存区域的地址和长度是在创建缓冲区时设置的。然后它们将变为只读。

4.5.1. doca_buf_head_get
该操作返回缓冲区指向的内存区域的地址。

doca_error_t doca_buf_head_get(struct doca_buf *buf, uint8_t **head);
在哪里：
buf – DOCA 缓冲区结构
head – 缓冲区指向的内存区域的地址（输出参数）
4.5.2. doca_buf_len_get
此操作返回缓冲区指向的内存区域的大小（以字节为单位）。

doca_error_t doca_buf_len_get(struct doca_buf *buf, size_t *len);
在哪里：
buf – DOCA 缓冲区结构
len – 缓冲区指向的内存区域的长度（输出参数）
4.5.3. doca_buf_refcount_rm
此操作会减少 doca_buf 引用计数。一旦达到零，该函数就会销毁 doca_buf 对象。

doca_error_t doca_buf_refcount_rm(struct doca_buf *buf, uint16_t *refcount);
在哪里：
buf – DOCA 缓冲区结构
refcount – 此操作发生之前的 doca_buf 引用计数值（输出参数）
4.5.4. doca_buf_refcount_get
此操作返回 doca_buf 引用计数值。

doca_error_t doca_buf_refcount_get(struct doca_buf *buf, uint16_t *refcount);
在哪里：
buf – DOCA 缓冲区结构
refcount – doca_buf 引用计数值（输出参数）

4.6. doca_buf_inventory
Note: All doca_buf_inventory operations are considered thread-unsafe.
The DOCA buffer inventory structure manages a pool of doca_buf objects. After creating doca_buf_inventory, the user must start the buffer inventory using doca_buf_inventory_start() function.

Each buffer allocated by doca_buf_inventory_buf_by_addr() points to a memory region of the users' choice.

Un-started/stopped buffer inventory rejects all attempts to allocate new DOCA Buffers, regardless of the number of free elements.

doca_buf_inventory_create
This operation allocates DOCA buffer inventory with the given attributes.

doca_error_t doca_buf_inventory_create(const char *name, size_t num_elements, uint32_t extensions, struct doca_buf_inventory **buf_inventory);
Where:
name – name of created DOCA buffer inventory
num_elements – number of elements in the inventory
num_elements – bitmap of extensions enabled for the inventory described in doca_buf.h
num_elements – DOCA buffer inventory on success (output parameter)
4.6.2. doca_buf_inventory_destroy
This operation destroys the DOCA buffer inventory structure and frees its memory. Before calling doca_buf_inventory_destroy all allocated buffers must be returned to the inventory.

doca_error_t doca_buf_inventory_destroy(struct doca_buf_inventory *inventory);
Where:
inventory – DOCA buffer inventory to destroy
4.6.3. doca_buf_inventory_property_set
This operation sets the value of a DOCA buffer inventory property.

doca_error_t doca_buf_inventory_property_set(struct doca_buf_inventory *inventory, enum doca_buf_inventory_property property, const uint8_t *value, uint32_t size);
Where:
inventory – DOCA buffer inventory structure
property – the requested property to set. See enum doca_buf_inventory_property.
value – the new value of the property
size – the size of the property in bytes
Note: All DOCA buffer inventory properties available at this stage are read-only properties.
4.6.4. doca_buf_inventory_property_get
This operation gets the up-to-date value of a DOCA buffer inventory property.

doca_error_t doca_buf_inventory_property_get(struct doca_buf_inventory *inventory, enum doca_buf_inventory_property property, const uint8_t *value, uint32_t size);
Where:
inventory – DOCA buffer inventory structure
property – the requested property to get. See enum doca_buf_inventory_property.
value – the value of the property (output parameter)
size – the size of the property in bytes
4.6.5. doca_buf_inventory_start
This operation starts DOCA buffer inventory.

doca_error_t doca_buf_inventory_start(struct doca_buf_inventory *inventory);
Where:
inventory – DOCA buffer inventory to start
4.6.6. doca_buf_inventory_stop
This operation stops DOCA buffer inventory.

doca_error_t doca_buf_inventory_stop(struct doca_buf_inventory *inventory);
Where:
inventory – DOCA buffer inventory to stop

4.6. doca_buf_inventory
注意：所有 doca_buf_inventory 操作都被视为线程不安全。
DOCA 缓冲区库存结构管理 doca_buf 对象池。创建 doca_buf_inventory 后，用户必须使用 doca_buf_inventory_start() 函数启动缓冲区清单。

doca_buf_inventory_buf_by_addr() 分配的每个缓冲区都指向用户选择的内存区域。

未启动/停止的缓冲区库存会拒绝所有分配新 DOCA 缓冲区的尝试，无论空闲元素的数量有多少。

doca_buf_inventory_create
此操作分配具有给定属性的 DOCA 缓冲区库存。

doca_error_t doca_buf_inventory_create(const char *name, size_t num_elements, uint32_t 扩展, struct doca_buf_inventory **buf_inventory);
在哪里：
name – 创建的 DOCA 缓冲区清单的名称
num_elements – 库存中的元素数量
num_elements – 为 doca_buf.h 中描述的清单启用的扩展位图
num_elements – 成功时的 DOCA 缓冲区库存（输出参数）
4.6.2. doca_buf_inventory_destroy
此操作会破坏 DOCA 缓冲区库存结构并释放其内存。在调用 doca_buf_inventory_destroy 之前，所有分配的缓冲区必须返回到清单中。

doca_error_t doca_buf_inventory_destroy(struct doca_buf_inventory *inventory);
在哪里：
库存 – DOCA 缓冲库存以销毁
4.6.3. doca_buf_inventory_property_set
此操作设置 DOCA 缓冲区库存属性的值。

doca_error_t doca_buf_inventory_property_set(struct doca_buf_inventory *inventory, enum doca_buf_inventory_property property, const uint8_t *value, uint32_t size);
在哪里：
库存 – DOCA 缓冲库存结构
property – 请求设置的属性。请参阅枚举 doca_buf_inventory_property。
value – 财产的新价值
size – 属性的大小（以字节为单位）
注意：此阶段可用的所有 DOCA 缓冲区库存属性都是只读属性。
4.6.4. doca_buf_inventory_property_get
此操作获取 DOCA 缓冲区库存属性的最新值。

doca_error_t doca_buf_inventory_property_get(struct doca_buf_inventory *inventory, enum doca_buf_inventory_property property, const uint8_t *value, uint32_t size);
在哪里：
库存 – DOCA 缓冲库存结构
property – 请求获取的属性。请参阅枚举 doca_buf_inventory_property。
value – 属性的值（输出参数）
size – 属性的大小（以字节为单位）
4.6.5。 doca_buf_inventory_start
此操作启动 DOCA 缓冲区库存。

doca_error_t doca_buf_inventory_start(struct doca_buf_inventory *inventory);
在哪里：
库存 – DOCA 缓冲库存启动
4.6.6。 doca_buf_inventory_stop
此操作会停止 DOCA 缓冲区库存。

doca_error_t doca_buf_inventory_stop(struct doca_buf_inventory *inventory);
在哪里：
库存 – DOCA 缓冲库存停止

4.6.7. doca_buf_inventory_buf_by_addr
This operation takes a single DOCA buffer from the DOCA buffer inventory and points it to a memory region from the DOCA memory map using the given addr and len arguments.

The given address and length must be contained in one of the memory ranges of the DOCA memory map. The operation fails if there is no such suitable memory range.

doca_error_t doca_buf_inventory_buf_by_addr(struct doca_buf_inventory *inventory, struct doca_mmap *mmap, char *addr, size_t len, struct doca_buf **buf);
Where:
inventory – DOCA buffer inventory structure
mmap – DOCA memory map structure
addr – the address of the memory region for the new doca_buf to point to
len – the length of the memory region for the new doca_buf to point to in bytes
buf – DOCA buffer object (output parameter)
4.6.8. doca_buf_inventory_buf_dup
This operation duplicates the source buffer by taking a new destination buffer from the given DOCA buffer inventory and copying the source buffer content to the destination buffer.

4.6.7. doca_buf_inventory_buf_by_addr
此操作从 DOCA 缓冲区清单中获取单个 DOCA 缓冲区，并使用给定的 addr 和 len 参数将其指向 DOCA 内存映射中的内存区域。

给定的地址和长度必须包含在 DOCA 内存映射的内存范围之一中。如果没有这样合适的内存范围，操作将失败。

4.7. doca_mmap
Note: All doca_mmap operations are considered thread-unsafe.
The DOCA memory map (mmap) structure points to a collection of memory ranges from a single address space; either the host or DPU memory.

The following are not possible on exported doca_mmap or on doca_mmap that has been created from export:
Setting the properties of the doca_mmap using doca_mmap_property_set()
Adding a device to the doca_mmap using doca_mmap_dev_add()
Removing a device to the doca_mmap using doca_mmap_dev_rm()
Adding a memory range to the doca_mmap using doca_mmap_populate()
Exporting the doca_mmap using doca_mmap_export()
4.7.1. doca_mmap_create
This operation allocates zero-size memory map object with default/unset attributes.

doca_error_t doca_mmap_create(const char *name, struct doca_mmap **mmap);
Where:
name – name of created DOCA memory map
mmap – DOCA memory map structure with default/unset attributes on success
4.7.2. doca_mmap_destroy
This operation destroys DOCA memory map structure and frees its memory. Before calling doca_mmap_destroy, all allocated buffers must be returned to the doca_mmap.

doca_error_t doca_mmap_destroy(struct doca_mmap *mmap);
Where:
mmap – DOCA memory map to destroy
4.7.3. doca_mmap_property_set
This operation sets the value of a DOCA memory map property.

doca_error_t doca_mmap_property_set(struct doca_mmap *mmap, enum doca_mmap_property property, const uint8_t *value, uint32_t size);
Where:
mmap – DOCA memory map structure
property – the requested property to set. See enum doca_mmap_property.
value – the new value of the property
size – the size of the property in bytes
4.7.4. doca_mmap_property_get
This operation gets the up-to-date value of a DOCA memory map property.

doca_error_t doca_mmap_property_get(struct doca_mmap *mmap, enum doca_mmap_property property, const uint8_t *value, uint32_t size);
Where:
mmap – DOCA memory map structure
property – the requested property to get. See enum doca_mmap_property.
value – the value of the property (output parameter)
size – the size of the property in bytes
4.7.5. doca_mmap_start
This operation starts the DOCA memory map.

doca_error_t doca_mmap_start(struct doca_mmap *mmap);
Where:
mmap – DOCA memory map to start
4.7.6. doca_mmap_stop
This operation stops the DOCA memory map.

doca_error_t doca_mmap_stop(struct doca_mmap *mmap);
Where:
mmap – DOCA memory map to stop