DOCA UROM 服务指南
本指南介绍如何在 NVIDIA® BlueField® 网络平台之上使用 DOCA UROM 服务。
DOCA UROM 服务为直接从主机卸载 HPC 软件堆栈的重要部分到 BlueField 设备提供了一个框架。
通过使用守护程序，该服务处理资源发现、主机和 BlueField 之间的协调，以及 BlueField worker 自身的生成、管理和拆卸。
启动卸载请求的第一步涉及 UROM 主机应用程序与 UROM 服务建立连接。收到插件发现命令后，UROM 服务通过向应用程序提供 BlueField 上可用的插件列表来做出响应。然后，应用程序将与所需 worker 对应的插件 ID 附加到其网络标识符。最后，该服务在 BlueField 上触发 UROM worker 插件实例以执行并行计算任务。在服务的 Kubernetes Pod 中，worker 由守护程序响应这些卸载请求而生成。每个计算都可以使用单个库或多个计算库。
在部署 UROM 服务容器之前，请确保满足以下先决条件
根据 DOCA 的需要分配巨页
$ echo
'2048'| sudo tee -a /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages $ sudo mkdir /mnt/huge $ sudo mount -t hugetlbfs -o pagesize=2M nodev /mnt/huge
有关在 BlueField 之上部署 DOCA 容器的信息，请参阅NVIDIA BlueField 容器部署指南。
特定于服务的配置步骤和部署说明可以在服务的容器页面下找到。
插件发现和报告
当应用程序启动与 DOCA UROM 服务的连接请求时，守护程序读取 UROM_PLUGIN_PATH 环境变量。此变量存储 .so 文件的目录路径，多个路径用分号分隔。守护程序按顺序扫描这些路径，并尝试加载每个 .so 文件。守护程序完成扫描后，它会将可用的 BlueField 插件报告给主机应用程序。
主机应用程序获取可用插件列表，作为 doca_urom_service_plugin_info 结构的列表
struct doca_urom_service_plugin_info {
uint64_t id; // Unique ID to send commands to the plugin
uint64_t version; // Plugin version
char plugin_name[DOCA_UROM_PLUGIN_NAME_MAX_LEN]; // .so filename
};
UROM 守护程序负责为插件生成唯一标识符，这对于使 worker 能够区分不同的插件任务是必要的。
在 Worker 中加载插件
在 UROM 守护程序生成 UROM worker 期间，守护程序在 worker 命令行中附加所需插件的列表。每个插件都以 so_path:id 格式传递。
作为 worker 引导的一部分，流程迭代所有 .so 文件，并尝试使用 dlopen 系统调用加载它们，并查找 urom_plugin_get_iface() 符号以获取插件操作接口。
Yaml 文件
从 NGC 下载的 .yaml 文件可以根据用户的需要轻松编辑
env:
# Service-Specific command line arguments
- name: SERVICE_ARGS
value: "-l 60 -m 4096"
- name: UROM_PLUGIN_PATH
value: "/opt/mellanox/doca/samples/doca_urom/plugins/worker_sandbox/;/opt/mellanox/doca/samples/doca_urom/plugins/worker_graph/"
SERVICE_ARGS是服务接收的运行时参数-l,--log-level <value>– 设置程序的（数字）日志级别<10=DISABLE, 20=CRITICAL, 30=ERROR, 40=WARNING, 50=INFO, 60=DEBUG, 70=TRACE>--sdk-log-level– 设置程序的 SDK（数字）日志级别<10=DISABLE, 20=CRITICAL, 30=ERROR, 40=WARNING, 50=INFO, 60=DEBUG, 70=TRACE>-m,--max-msg-size– 指定 UROM 通信通道最大消息大小
UROM_PLUGIN_PATH是一个 env 变量，用于存储插件的.so文件的目录路径
对于 BlueField 上的每个插件，都需要在服务容器内添加卷挂载。例如
volumes:
- name: urom-sandbox-plugin
hostPath:
path: /opt/mellanox/doca/samples/doca_urom/plugins/worker_sandbox
type: DirectoryOrCreate
...
volumeMounts:
- mountPath: /opt/mellanox/doca/samples/doca_urom/plugins/worker_sandbox
name: urom-sandbox-plugin
当排除容器部署问题时，强烈建议遵循“查看容器部署”部分和 DOCA 容器部署指南 中找到的部署步骤和技巧。
还可以检查 /var/log/doca/urom 日志文件，以获取有关服务组件（守护程序和 worker）运行周期的更多详细信息。
worker 的日志文件名是 urom_worker_<pid>_dev.log，守护程序的日志文件名是 urom_daemon_dev.log。
Pod 标记为“就绪”但未列出容器
错误
当部署容器时，Pod 的 STATE 标记为 Ready，并且列出了镜像，但是，看不到容器正在运行
$ sudo crictl pods
POD ID CREATED STATE NAME NAMESPACE ATTEMPT RUNTIME
3162b71e67677 4 seconds ago Ready doca-urom-my-dpu default 0 (default)
$ sudo crictl images
IMAGE TAG IMAGE ID SIZE
k8s.gcr.io/pause 3.2 2a060e2e7101d 487kB
nvcr.io/nvidia/doca/doca_urom 1.0.0-doca2.7.0 2af1e539eb7ab 86.8MB
$ sudo crictl ps
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD
解决方案
在大多数情况下，容器已启动但立即退出。可以使用以下命令检查这一点
$ sudo crictl ps -a
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD
556bb78281e1d 2af1e539eb7ab 6 seconds ago Exited doca-urom 1 3162b71e67677 doca-urom-my-dpu
如果容器失败（即，报告 Exited 状态），建议检查 /var/log/doca/urom/urom_daemon_dev.log 中的 UROM 主日志。
此外，在终止后的短时间内，也可以使用容器的 ID 查看容器日志
$ sudo crictl logs 556bb78281e1d
...
Pod 未列出
错误
当将容器的 YAML 文件放在 Kubelet 的输入文件夹中时，服务 Pod 未在 Pod 列表中列出
$ sudo crictl pods
POD ID CREATED STATE NAME NAMESPACE ATTEMPT RUNTIME
解决方案
在大多数情况下，Pod 未启动是因为缺少请求的巨页。可以使用以下命令进行验证
$ sudo journalctl -u kubelet -e. . .
Oct 04 12:12:19 <my-dpu> kubelet[2442376]: I1004 12:12:19.905064 2442376 predicate.go:103] "Failed to admit pod, unexpected error while attempting to recover from admission failure" pod="default/doca-urom-service-<my-dpu>" err="preemption: error finding a set of pods to preempt: no set of running pods found to reclaim resources: [(res: hugepages-2Mi, q: 104563999874), ]"