代码之家  ›  专栏  ›  技术社区  ›  maxschlepzig

用于传输的正确DPDK设备和端口初始化

  •  0
  • maxschlepzig  · 技术社区  · 3 年前

    在编写一个简单的DPDK数据包生成器时,我注意到可靠和成功的数据包传输需要一些额外的初始化步骤:

    1. rte_eth_link_get() rte_eth_timesync_enable() 之后 rte_eth_dev_start()
    2. 在发送第一个数据包之前等待2秒 rte_eth_tx_burst()

    因此,当我将ixgbe DPDK vfio驱动程序与Intel X553 NIC一起使用时,这些步骤是必要的。

    当我使用 AF_PACKET DPDK驱动程序,无需额外步骤即可工作。

    • 有没有比第一次发送前等待2秒更好的方法?
    • 是否有比调用更惯用的函数 rte_eth_link_get() 为了完成传输的设备初始化?

    其他信息: 当我将NIC连接到镜像端口时(通过Mikrotik的镜像源/镜像目标以太网交换机设置进行配置) 这个 sleep(2)

    在第一次传输前仅等待1秒,可靠性较低,即数据包仅每隔奇数次到达接收器。

    我的设备/端口初始化过程执行以下设置顺序:

    rte_eth_dev_count_avail()
    rte_eth_dev_is_valid_port()
    rte_eth_dev_info_get()
    rte_eth_dev_adjust_nb_rx_tx_desc()
    rte_eth_dev_configure(port_id, 0 /* rxrings */, 1 /* txrings */, &port_conf)
    rte_eth_tx_queue_setup()
    rte_eth_dev_start()
    rte_eth_macaddr_get()
    
    rte_eth_link_get()  // <-- REQUIRED!
    
    rte_eth_dev_get_mtu()
    

    没有 rte_eth_link_get() (或 )第一个传输的数据包甚至没有出现在镜像端口上。

    上述功能(以及 rte_eth_tx_burst() rte_eth_link_get() 睡眠(2) 在场。特别是,读取MAC地址MTU具有预期值(MTU->1500)和 rte_eth_tx_burst() 返回 1

    返回的链接状态为: Link up at 1 Gbps FDX Autoneg

    事实是 rte_eth_link_get() rte_eth_timesync_enable() ixgbe_start_timecounters() 哪个叫 rte_eth_linkstatus_get() 也叫 rte_eth_link_get() .

    我已经检查了DPDK示例,其中大多数都没有调用 rte_eth_link_get()

    我使用的是DPDK20.11.2。


    -回答评论:

    5.13.12-100.fc33.x86_64 ).

    Ethtool报告: firmware-version: 0x80000877

    我打过电话 rte_eth_timesync_enable() rte_eth_link_get()

    当切换到 自动对焦包 我使用的是股票ixgbe内核驱动程序,即。 ixgbe 在由networkd初始化的设备上使用默认设置(启用dhcp)。

    我的期望是当

    不过,我想,如果能避免在程序重新启动后重置设备,那就太好了。我不知道DPDK是否支持这个。

    rte_eth_link_get() rte_eth_link_get() 需要3.3秒。所以,是的,它可能只是帮助由于额外的延迟。

    0 回复  |  直到 3 年前
        1
  •  1
  •   Ivan 4D    3 年前

    两种尝试方法之间的差异

    为了使用 af_packet PMD,首先将有问题的设备绑定到内核驱动程序。此时,将为该设备生成一个内核网络接口。默认情况下,此接口通常会激活链接。如果不是,则通常运行 ip link set dev <interface> up 。启动DPDK应用程序时, 自动对焦包 https://github.com/DPDK/dpdk/blob/main/drivers/net/af_packet/rte_eth_af_packet.c#L266 )当设备停止时,反之亦然。链接更新操作在此驱动程序中也没有操作(请参阅 https://github.com/DPDK/dpdk/blob/main/drivers/net/af_packet/rte_eth_af_packet.c#L416 ).

    事实上 方法,则在启动应用程序时链接已处于活动状态。因此无需等待链接。

    通过VFIO方法,相关设备的链路断开,相应的PMD负责激活它。因此,需要在应用程序中测试链路状态。

    长话短说,是的。等待链接状态不是应用程序重新启动的唯一问题。当您重新启动时,您可以有效地将EAL作为一个整体重新初始化,并且该过程也非常耗时。为了解决这个问题,你可能应该退房 在DPDK中提供(参见 https://doc.dpdk.org/guides/prog_guide/multi_proc_support.html ).

    这要求您重新实现应用程序,使其控制逻辑在一个进程中(也就是 初级过程 )和另一个中的Rx/Tx数据路径逻辑( 二次过程 )。这样,您可以保持第一个始终运行,并在需要更改Rx/Tx逻辑/重新编译时重新启动第二个。重新启动

        2
  •  1
  •   Vipin Varghese    3 年前

    基于评论的互动,真正的问题是

    简单的回答是 No 对于重启之间的数据包生成器程序,因为任何使用PCIe配置空间与uio_pci_generic | igb_uio | vfio pci绑定的PF(用于X533的IXGBE)和VF(用于X553的IXGBE_VF)的物理NIC都需要 PCIe重置&配置 但是,当使用AF_数据包(ixgbe内核驱动程序)DPDK PMD时,这是 直接 dev->data->dev_link.link_status = ETH_LINK_UP; 在eth_dev_start函数中。

    第二部分 第一个发送数据包的延迟是否为预期值?

    [答:]没有,因为一些因素会导致第一次数据包传输的延迟

    • 交换机端口自动负或固定速度(仅限PF)
    • X533软件和固件(PF和VF)
    • 链路介质SFP(光纤)或DAC(直连铜缆)或RJ-45(cat5 | cat6)连接(仅限PF)
    • NIC的PF驱动程序版本(X553 ixgbe) (PF和VF)
    • 根据英特尔驱动程序 软件生成的第二层帧,如IEEE 802.3x(链路流控制)、IEEE 802.1Qbb(基于优先级的流控制)和其他此类帧 (仅限VF)

    1. 从PF上的管理接口为VLAN标记配置所有启用SR-IOV的端口,以避免流量涌入VF
    2. PF驱动程序已更新,以避免旧的驱动程序问题,例如(VF复位导致PF链路复位)。这可以通过检查来识别 dmesg

    1. 禁用DPDK X533的自动负,并比较DPDK中的PF与Vf

    通过以下步骤隔离开关故障:

    1. FD auto-neg-disable speed 1Gbps 并检查其行为

    [EDIT-1]我同意@stackinside使用DPDK主次流程概念提出的解决方案。作为主要负责人,负责链路和端口的建立。而二级用于实际接收和发送突发。