【原创】关于xenomai3 RTnet的一点记录
一、RTnet注意事项
- xenomai3协议栈RTnet支持TCP、UDP,但不支持IGMP;
- 对ARP支持有限制:地址解析的延迟会影响数据包传输延迟,RTnet为实时性考虑,路由表设计静态的,只在设置期间配置,或者接收到其他机器A发出的的ARP请求才会将A的路由信息添加到路由表。如果我们访问的IP是未知目标MAC地址,不会发出解析请求,直接报错。如果我们不能配置路由表,这会影响我们作为客户端去连接服务端时,出现找不到服务端。
- RTnet TCP作为服务端时,每个服务端端口同时只允许一个客户端连接,这算是什么服务端!!!!
- 关于
CONFIG_XENO_DRIVERS_NET_ADDON_PROXY_ARP配置说明:
-
CONFIG_XENO_DRIVERS_NET_ADDON_PROXY_ARP启用时:-
rtproxy 与rtnet设备MAC地址相同
-
RTnet接收的ARP请求由linux接收处理,但rtnet接收到ARP回复会记录到rtroute表中
即若没有启用rtproxy ,无法ping通rtnet的IP
-
linux路由表
-
rtping不能使用,只能使用linux ping
-
linux发送时,直接通过rtnet网卡发送
-
对于每一个IP帧,先检查rtnet是否接收,rtnet不接收才转发给rtproxy ,对于rtnet不支持的ip协议,直接转发
-
-
CONFIG_XENO_DRIVERS_NET_ADDON_PROXY_ARP关闭后:- rtproxy 设备MAC地址为 0:0:0:0:0:0,且不支持ARP(
dev->flags |= IFF_NOARP),rtproxy 设备不支持组播。 - RTnet接收的ARP请求由RTnet处理并回复
- linux发送时,先查询rtroute,然后修改linux发送的数据包,源MAC修改为rtnet设备的MAC,目的MAC为路由表中获取(缺点是rtroute的路由表是静态的)
- rtproxy 设备MAC地址为 0:0:0:0:0:0,且不支持ARP(
-
TCP/IP本就不是实时的,xenomai3全部用rtnet实现可用性太低,但在实际实时以太网应用中,基本只用到二层实时网络收发,不涉及三层及以上协议,所以xenomai4中evl核中基于linux扩展,实时只支持raw packet是非常正确的做法!
-
在一些应用场合我们需要控制phy,或者读写phy寄存器信息,但rtnet ioctl没有linux的ioctl全面,没有相关接口,这类接口需要自己在socket.c中添加,同时网卡驱动中同步增加。
二、RTnet数据结构

以下文章包含rtnet数据结构的详细分析
1. 实时IPC概述
2. 实时与非实时通讯XDDP
xenomai与普通linux进程之间通讯XDDP(一)--实时端socket创建流程
xenomai与普通linux进程之间通讯XDDP(二)--实时与非实时关联(bind流程)
xenomai与普通linux进程之间通讯XDDP(三)--实时与非实时数据交互
更多信息参见:https://source.denx.de/Xenomai/xenomai/-/wikis/RTnet_Basics
关键问题及回答
问题1:RTnet的包管理策略是如何设计的,特别是在处理发送和接收包时有哪些关键措施?
RTnet的包管理策略设计得非常精细,特别是在处理发送和接收包时。以下是几个关键措施:
预分配rtskb:为了避免内存碎片化,所有rtskb(实时套接字缓冲区)在初始化期间预先分配。每个rtskb都有一个固定的大小,能够携带最大的物理包。
包生产者-消费者模型:包生产者和消费者需要创建rtskb池,参与通信时从池中获取rtskb,处理完成后将rtskb返回池中。这样可以确保包的高效利用和管理。
优先级管理:RTnet的堆栈管理器优先级高于所有使用RTnet服务的应用程序,以避免优先级反转。这与大多数操作系统中的下半部分中断处理类似。
统一数据结构:堆栈和驱动使用统一的rtskb数据结构来处理包缓冲区。这种设计简化了缓冲区的管理和数据交换。
通过这些措施,RTnet能够高效地管理包,确保硬实时通信的可靠性和性能。
问题2:RTnet的UDP/IP实现有哪些修改以确保确定性?具体做了哪些优化?
RTnet的UDP/IP实现进行了多项修改以确保确定性,主要包括以下几点:
静态ARP机制:动态ARP被转换为静态机制,在初始化期间执行一次。如果后续需要解析目标地址,不再发出ARP请求,而是直接返回传输错误。这样可以避免动态ARP带来的不确定性。
简化的路由过程:输出路由表被优化,以适应RTnet使用的有限条目数量。表中还包含了ARP结果,即目标硬件地址,以加速包的建立过程。
IP数据包去碎片化处理:在经典网络堆栈中,IP层的去碎片化任务在UDP层之前进行。RTnet通过一个全局rtskb池来缓冲所有片段,直到最后一个片段到达。新的片段添加到现有链表中时需要查找全局列表,未完成的链表在超时后被清理,以避免缓冲区短缺并保持全局IP片段列表的小尺寸。
接收套接字的精确时间戳:RTnet要求驱动程序在接收到每个包的开始时刻提供精确的接收时间戳,并在发送包时原子性地存储当前时间并触发传输。这些措施大大减少了包时间戳的抖动。
通过这些优化,RTnet的UDP/IP实现能够提供确定性的传输服务,满足硬实时通信的需求。
问题3:RTnet的实时配置服务(RTcfg)有哪些关键功能,如何支持新节点的加入和网络监控?
RTnet的实时配置服务(RTcfg)设计为一个纪律和媒体无关的服务,具有以下关键功能:
新节点加入:RTcfg支持新节点的加入。节点通过接收初始参数包来启动,这些参数包含设置RTmac纪律所需的最基本信息。节点在初始化阶段完成配置后,宣布其存在,其他节点更新其地址信息。
节点监控:RTcfg提供节点监控功能,可以交换节点的物理和逻辑地址。这使得可以建立和维护静态ARP表,并在此基础上构建实时网络监控工具。
网络启动同步:RTcfg支持实时网络启动同步。特定的RTmac纪律或某些应用场景可能需要共同的会合点来切换网络模式或同步启动应用程序。
数据分发:RTcfg能够在没有TCP/IP的情况下分发任意配置数据。这对于通过其他协议(如TFTP/FTP)进行文件传输的场景尤为重要。
RTcfg基于客户端-服务器协议,中央配置服务器存储每个管理客户端的参数集。服务器连续邀请已知但尚未激活的客户端加入。客户端的启动过程分为三个阶段:接收初始参数、完成纪律初始化和宣布节点存在。通过这些功能,RTcfg能够有效地支持新节点的加入和网络监控,确保网络的稳定性和可扩展性
三、移植RTNet到PREEMPT-RT内核
github上有个研究型项目rtnet-preempt_rt,地址为https://github.com/laurentiuduca/rtnet-preempt_rt 下面是其介绍:
市面上有许多操作系统,但 Linux 因其免费、优秀的用户界面、连接性和图形功能,可以在通信、交易和控制系统等多种场景中使用。PREEMPT_RT 补丁为 Linux 带来了硬实时特性,但它缺少一个实时网络堆栈。RTnet 是一个成熟的硬实时开源网络堆栈。本文介绍了 RTnet 在 PREEMPT_RT Linux 内核 5.9 上的主要部分移植,以及运行的压力测试,以证明 RTnet 堆栈在 PREEMPT_RT Linux 上的效率。
它还适配了不少rtnet驱动,理论上可以在xenomai3中使用,分别是:
- ticpsw:适用于TI am335x\437x\572x系列SOC
- rpi-4/bcmgenet:适用于树莓派4|4B
- r8169:相比xenomai3内部的r8169更新的rtnet驱动,适用于r8169一系列网卡,如rtl8125、rtl8168、8167等等
- stmmac:适配的st的stmmac网卡,理论上使用该IP的soc均可使用,如rk3588、3568、全志T357等等
- microchip/enc28j60:适用于rpi-zero
Features:
- 移植到 raspberry pi 4 (bcmgenet)、orange pi one (stmmac)、realtek (8139too)、microchip (enc28j60)
注意:这个仓库中的 bbb 驱动程序没有移植到 rtnet-preempt_rt,我不记得当时为什么把它包含在内(两年前) - rtnet UDP 套接字,绑定,接收消息,发送到,接收来自,发送消息,选择,轮询系统调用(系统调用名称后附加了_rtnet(),但你可以重命名它们);recv 可能的超时;
- AF_INET(UDP)或 AF_PACKET(原始)家族的套接字;
- rtnetproxy 用于 ssh 和 scp(但使用 RT 驱动带宽)也请查看 rtnet-geek 仓库中的帮助文档。
- TODO:如果感兴趣,将移植routing、rtcfg、rtmac、tdma 和 nomac
- 可以在变量 msg_in_userspace 周围进行改进,例如避免多次数据包复制
Paper
if you use our work, please cite us: L. -C. Duca and A. Duca, "Achieving Hard Real-Time Networking on PREEMPT_RT Linux with RTnet" 2020 International Symposium on Fundamentals of Electrical Engineering (ISFEE), 2020, pp. 1-4, doi: 10.1109/ISFEE51261.2020.9756165.
https://ieeexplore.ieee.org/document/9756165

浙公网安备 33010602011771号