【DPDK】Trace Library

本文介绍: 当跟踪缓冲区已满时，新的跟踪事件会覆盖跟踪缓冲区中现有的捕获事件。事件记录模式是跟踪缓冲区的一个属性。当跟踪缓冲区已满时，将丢弃新的跟踪事件。使用 trace com pass GUI工具。使用 babel trace 命令行工具。查看和分析记录的事件。

概述

跟踪是一种用于了解运行中的软件系统中发生了什么的技术。用于跟踪的软件被称为跟踪器，在概念上类似于磁带记录器。记录时，放置在软件源代码中的特定检测点会生成保存在巨大磁带上的事件：跟踪文件。稍后可以在跟踪查看器中打开跟踪文件，以使用时间戳和多核视图可视化和分析跟踪事件。这样的机制将有助于解决一系列问题，如多核同步问题、延迟测量、找出分析后的信息（如CPU空闲时间）等这些信息将极具挑战性。
跟踪通常被比作日志记录。然而，跟踪器和记录器是两种不同的工具，用于两种不同目的。跟踪器被设计用于记录比日志消息更频繁发生的低级别事件，通常在每秒数千次的范围内，执行开销非常小。日志记录更适合于对不太频繁的事件进行非常高级的分析：用户访问、异常情况（例如错误和警告）、数据库事务、即时消息通信等等。简单地说，日志记录是可以满足跟踪的众多用例之一。

DPDK跟踪库功能

一个在控制和快速路径API中添加跟踪点的框架，对性能的影响最小。典型的跟踪开销约为20个c y cle，指令开销为1个cycle。
在运行时启用和禁用跟踪点。
在任何时间点将跟踪缓冲区保存到文件系统。
支持覆盖和放弃跟踪模式操作。
基于字符串的跟踪点对象查找。
基于正则表达式和/或gl o b bing启用和禁用一组跟踪点。
以通用跟踪格式（CTF）生成跟踪。CTF是一种开源跟踪格式，与LTTng 兼容。有关详细信息，请参阅通用跟踪格式。

如何 添加跟踪点？

创建跟踪点头文件

#include &lt;rte_trace_point.h&gt;

RTE_TRACE_POINT(
       app_trace_string,
       RTE_TRACE_POINT_ARGS(const char *str),
       rte_trace_point_emit_string(str);
)

面的宏创建 app t rac k e string跟踪点。用户可以为跟踪点选择任何名称。但是，在DPDK库中添加跟踪点时，必须遵循rte_<library_name&g t;tr ace[_]命名约定。示例为rt e_e al_tr ace_g ener ic_str、rte_m em pool_tr ace_create。
RTE_TRACE_POINT宏从上述定义扩展为以下函数模板：

static __rte_always_inline void
app_trace_string(const char *str)
{
        /* Trace subsystem hooks */
        ...
        rte_trace_point_emit_string(str);
}

此跟踪点的使用者可以调用 a pp_trace_string（const char*str）将跟踪事件发送到跟踪缓冲区。

注册跟踪点

#include <rte_trace_point_register.h>

#include <my_tracepoint.h>

RTE_TRACE_POINT_REGISTER(app_trace_string, app.trace.string)

上面的代码片段注册了app_trace_string跟踪点到跟踪库。这里，my_trace port.h是用户在创建跟踪点头文件的第一步中创建的头文件。RTE_TRACE_POINT_REGISTER的第二个参数是跟踪点的名称。此字符串将用于跟踪点查找或正则表达式和/或基于 glob的跟踪点操作。不要求tracepoint 函数及其名称相似。但是，为了更好地命名约定，建议使用类似的名称。
备注：在包含 rte_trace_point.h标头之前，必须包含 rte_trace_point_register.h标头。
RTE_TRACE_POINT_REGISTER定义RTE_TRACE_POINT_t跟踪点对象的占位符。对于通用跟踪点或公共头文件中使用的跟踪点，用户必须在库.map 文件中导出一个__<trace_function_name>符号，以便在共享构建中在库外使用此跟踪点。例如，__app_trace_string将是上面示例中导出的符号。

快速路径跟踪点

为了避免快速路径代码中的性能影响，库引入了RTE_TRACE_POINT_FP。在快速路径代码中添加跟踪点时，用户必须使用RTE_TRACE_POINT_FP而不是RTE_RACE_POINT。
RTE_TRACE_POINT_FP在默认情况下编译出来，并且可以使用用于介子构建的enable_TRACE_FP选项来启用它。

事件记录模式
事件记录模式是跟踪缓冲区的一个属性。跟踪库有以下模式：
覆盖
当跟踪缓冲区已满时，新的跟踪事件会覆盖跟踪缓冲区中现有的捕获事件。
丢弃
当跟踪缓冲区已满时，将丢弃新的跟踪事件。

模式可以在应用程序启动时使用EAL命令行参数–trace-mode进行配置，也可以在运行时使用 rte_trace_mode_set（）API进行配置。

跟踪文件 位置

在调用rte_trace_sa ve（）或rte_eal_cleanup（）时，库将跟踪缓冲区保存到文件系统。默认情况下，跟踪文件存储在$HOME/dp d k-traces/rte-yyyy–mm–d d-[AP]M-hh–mm–ss/中。它可以被–trace dir=EAL命令行选项覆盖。有关更多信息，请参阅跟踪EAL命令行选项的EAL参数。

查看和分析记录的事件

一旦跟踪目录可用，用户就可以查看/检查记录的事件。您可以使用许多工具来读取DPDK跟踪：
babeltrace是一个命令行实用程序，用于转换跟踪格式；它支持DPDK跟踪库生成的格式CTF，以及可以被grep’ed的基本文本输出。b ab eltrace命令是开源 b abeltrace项目的一部分。Trace Com pass是一个图形用户界面，用于查看和分析任何类型的日志或跟踪，包括DPDK跟踪。

使用b abeltrace命令行工具

列出跟踪的所有记录事件的最简单方法是将其路径传递到b abeltrace，无需任何选项：b abeltrace递归地找到给定路径中的所有轨迹，并打印它们的所有事件，按时间顺序合并它们。

babeltrace </path-to-trace-events/rte-yyyy-mm-dd-[AP]M-hh-mm-ss/>

您可以将b abeltrace的输出通过管道传输到grep（1）这样的工具中进行进一步的过滤。下面的示例仅对eth dev的事件进行grep：

babeltrace /tmp/my-dpdk-trace | grep ethdev

您可以将babeltrace的输出通过管道传输到类似wc（1）的工具中，以计数记录的事件。以下示例统计 eth dev事件的数量：

babeltrace /tmp/my-dpdk-trace | grep ethdev | wc --lines

使用tracecom pass GUI工具

Tracecom pass是另一个查看/分析DPDK跟踪的工具，它提供了事件的图形视图。与babeltrace一样，tracecom pass也提供了一个搜索特定事件的界面。要使用tracecom pass，至少需要以下步骤：
将tracecom pass 安装到本地主机。变体可用于Linux、Windows和OS-X。
启动tracecom pass，它将打开一个带有跟踪管理界面的图形窗口。
使用“文件”->“打开跟踪”选项打开跟踪，然后选择要查看/分析的元数据文件。
有关更多详细信息，请参阅Trace Com pass。

快速启动

本节将逐步介绍生成跟踪和查看跟踪的详细信息。
启动 dpdk测试：

echo "quit" | ./build/app/test/dpdk-test --no-huge --trace=.*

使用babeltrace查看器查看轨迹：

babeltrace $HOME/dpdk-traces/rte-yyyy-mm-dd-[AP]M-hh-mm-ss/

实施细节

由于DPDK跟踪库旨在生成使用公共跟踪格式（CTF）的跟踪。CTF规范由以下创建跟踪的单元组成。
数据包的流序列。
数据包标头和一个或多个事件。
事件标头和有效负载。
有关详细信息，请参阅通用跟踪格式。

实施细节大致分为以下几个方面：

跟踪元数据创建

根据CTF规范，CTF跟踪的流之一是强制性的：元数据流。它包含了您所期望的内容：关于跟踪本身的数据。元数据流包含所有其他流的二进制布局的文本描述。此描述是使用跟踪流描述语言（TSDL）编写的，TSDL是一种仅存在于CTF领域的声明性语言。元数据流的目的是让CTF读者知道如何在不指定任何固定布局的情况下解析跟踪的二进制事件流。事实上，唯一预先知道的流布局是元数据流的布局。内部trace_meta data_create（）函数生成元数据。

跟踪内存

跟踪内存将通过内部函数 __rte_trace_mem_per_thread_alloc（）进行分配。跟踪内存将按线程分配，以启用无锁跟踪发射功能。对于非lcore 线程，跟踪内存是在第一次跟踪发射时分配的。对于lcore 线程，如果通过EAL选项启用了跟踪点，则当线程知道DPDK时，将分配跟踪内存（对于EAL lcores为rte_EAL_init，对于非EAL lcore为rte_th read_register）。否则，当在应用程序的生命周期后期启用跟踪点时，行为与非lcore 线程相同，并且在第一次跟踪发射时分配跟踪内存。

跟踪内存布局
Trace memory layout

packet.header

uint32_t magic
rte_uuid_t uuid

packet.context

uint32_t thread_id
char thread_name[32]

trace.header

event_id [63:48]
timestamp [47:0]

跟踪标头为64位，由48位时间戳和16位事件ID组成。packet.header和packet.context将在创建跟踪内存时写入慢速路径。trace.header和trace有效负载将在调用tracepoint函数时发出。

限制

rte_trace_point_em it_blob（）函数可以捕获长度为rte_trace_blob_LEN_MAX字节的最大 blob。如果应用程序需要捕获超过rte_trace_blob_LEN_MAX字节的数据，则应用程序可以多次调用长度小于或等于rte_trace_blob_LEN_MAX的rte_trace_point_em it_blob（）。如果传递给rte_trace_point_emit_blob（）的长度小于rte_trace_blob_LEN_MAX，则跟踪中的尾部（rte_trace_blob_LEN_MAX-LEN）字节将设置为零。