• 状态
  • 已锁定 已锁定
  • 回复 10 回复
  • 订户 0 订户
  • 视图 199 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] PROCESSOR-SDK-AM64X：HSR 接口的最大 MTU

admin
Guru**** 2419530 points


请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1496057/processor-sdk-am64x-the-maximum-mtu-of-hsr-interface

器件型号：PROCESSOR-SDK-AM64X

工具/软件：

你(们)好

内核 HSR 子系统将 HSR 接口的最大 MTU 限制为1494、即最大 MTU (1500)减去 HSR 标签长度(6)、这是因为在添加 HSR 标签时、HSR 子系统占用 MTU 的一部分。 但是、在将 HSR 标签的插入过程转移到 PRU 固件后、HSR 接口的最大 MTU 可以恢复到1500。 似乎没有在驱动程序中实现。

没有在 Linux 驱动程序中实现此功能的原因是什么吗？ 您能在这一点上提供一些补丁吗？

指向的交叉点

https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/net/hsr/hsr_device.c?h=11.00.09#n107

非常感谢

  • 0
    TI__Guru**** 2419530 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Milan、

    Unknown 说：
    但是、在将 HSR 标签插入的过程被卸载到 PRU 固件后、HSR 接口的最大 MTU 可恢复到1500。 在驱动程序中似乎未实现此功能。

    为了进行澄清、您是否说过当 HSR 标签插入转移到 PRU 时、预计 HSR 接口的最大 MTU 应保持1500 (不限于 1494)？

    Unknown 说：
    是否有理由在 Linux 驱动程序中未实施此功能？ 您能否在这一点上提供一些补丁？

    我的理解是、我们的团队会修改 HSR_DEVICE.c、因为它不是 TI 特定的驱动程序、而是通常用于 Linux HSR (不是特定于 TI 以太网)的代码。 如果对此 MTU 大小有任何更改、我认为它们位于 icssg_prueth.c 驱动程序： https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/net/ethernet/ti/icssg/icssg_prueth.c?h=ti-rt-linux-6.6.y 中。 在初始查看此驱动程序时、我不会在任何位置明确看到 MTU 大小的地址。 让我与开发人员核实一下。

    -道林

  • 0
    TI__Guru**** 2419530 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Daolin：

    是的、关于 MTU 大小、它是正确的...

    HSR_DEVICE.c 不是 TI 特定的、但有一些您需要并进行了修改的示例...

    https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/net/hsr/hsr_device.c?h=11.00.09&id=e748d0fd66abc4b1c136022e4e053004fce2b792

    也许修改不复杂、我们也可以...

    但首先,如果我们没有看到这种修改的一些问题,我们想了解影响。 如果它在您的存储库中、我们可以更轻松地重复使用、共享和维护...  

  • 0
    TI__Guru**** 2419530 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Milan、

    Unknown 说：
    是的、关于 MTU 大小是正确的...

    在已卸载 HSR 的情况下、需要将 HSR 接口恢复到1500是否有特定的原因？ 换言之、您尝试测试/实施的特定功能是否需要更改为1500？

    [引述 userid="488374" url="~/support/processors-group/processors/f/processors-forum/1496057/processor-sdk-am64x-the-maximum-mtu-of-hsr-interface/5749429 #5749429"]

    也许修改不复杂、我们也可以...

    但首先,如果我们没有看到这种修改的一些问题,我们想了解影响。 如果它在您的存储库中、我们可以更轻松地重复使用、共享和维护...  

    [/报价]

    我尝试在固件端内部与团队核实 HSR 标签插入如何处理 MTU 大小限制。 如果我发现任何问题、我会告诉您。

    -道林

  • 0
    TI__Guru**** 2419530 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Daolin：

    HSR 性能测试需要最大帧长度才能支持多达1528字节(14字节以太网标头+ 4字节 VLAN 标签+ 6字节 HSR 标签+ 1500字节 MTU + 4字节 FCS)

  • 0
    TI__Guru**** 2419530 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Milan、  

    我们的 Linux 开发人员上周已不在办公室、他计划本周检查、我将在了解更多信息后更新。 如果我在周四或周五没有回复更新、请再次 ping 此主题。

    从固件方面、固件开发人员告知我、当 HSR 标签插入转移到 PRU 固件时、固件不会处理任何与长度相关的检查。

    -道林

  • 0
    TI__Guru**** 2419530 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Milan、  

    对延迟响应表示歉意。

    [引述 userid="488374" url="~/support/processors-group/processors/f/processors-forum/1496057/processor-sdk-am64x-the-maximum-mtu-of-hsr-interface/5749429 #5749429"]

    也许修改不复杂、我们也可以...

    但首先,如果我们没有看到这种修改的一些问题,我们想了解影响。 如果它在您的存储库中、我们可以更轻松地重复使用、共享和维护...  

    [/报价]

    从 Linux 的角度来看、对于卸载和非卸载的情况、我们不会从驱动程序端对 MTU 大小进行任何特殊修改。 我们的开发人员描述了" HSR 器件的 MTU hsr0 由内核堆栈修改 hsr_dev_change_mtu() 、其中重要 1500-6 的是使 MTU = 1494。 这是在期间发生的  hsr_add_port()"

    在进行修改时、我可以看到的主要问题是、当 HSR 标签插入转移到固件时、从固件侧没有与帧长度相关的检查。 因此、如果您将 HSR 接口的最大 MTU 恢复为1500B、并且固件插入6字节 HSR 标签、则总帧大小将为1506B、因为不会检查固件。

    Unknown 说：
    HSR 性能测试要求最大帧长度、最多可支持1528字节(14字节以太网标头+ 4字节 VLAN 标记+ 6字节 HSR 标签+ 1500字节 MTU + 4字节 FCS)[/报价]

    对最大帧长度的这种描述似乎从1500B MTU 中排除了6B HSR 标签？ 我完全不理解 HSR 标签是计入1500B MTU 还是不应该是 MTU 的一部分...  

    Unknown 说：
    内核 HSR 子系统将 HSR 接口的最大 MTU 限制为1494、即最大 MTU (1500)减去 HSR 标签长度(6)、这是因为在添加 HSR 标签
    时 HSR 子系统占用 MTU 的一部分

    在这里、暗示在添加 HSR 标签时、HSR 标签占据 MTU 的一部分...

    -道林

    [/quote]
  • 0
    TI__Guru**** 2419530 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    道林：

    在进行修改时、我可以看到的主要问题是、当 HSR 标签插入转移到固件时、从固件侧没有与帧长度相关的检查。 因此、如果您将 HSR 接口的最大 MTU 恢复为1500B、并且固件插入6字节 HSR 标签、则总帧大小将为1506B、因为不会检查固件。

    答：我想如果您更改内核驱动程序并检查是否有卸载、您可以添加这些6b。 可以检查是否在内核驱动程序中配置了 HSR 卸载、并根据这一决定是否添加6B

  • 0
    TI__Guru**** 2419530 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Milan、  

    Unknown 说：
    MS：我想如果您更改内核驱动程序并检查是否有卸载、您可以添加这些6b。 是否可以检查是否在内核驱动程序中配置了 HSR 卸载、并根据这一决定添加或不添加6B

    当您提到"内核驱动程序"时、您引用的是 hsr_device.c https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/net/hsr/hsr_device.c?

    此外、如果我正确理解您、 通过"添加6B"、您的意思不是实际的 HSR 标签插入、而是在此内核驱动程序中将 MTU 大小从1494B 恢复到1500B？ 如果是、我不确定这如何解决以下问题：固件看到的总帧大小为1506B (因为固件在卸载 HSR 时会执行实际的 HSR 标签插入)。

    如果您所说的"添加6b"实际上是使 HSR 标签插入不再由固件执行、而只是让该内核驱动程序插入 HSR 标签、那么这将不再是完全的 HSR 卸载(因为 HSR 标签插入实际上不会卸载到固件)。 如果这就是您的意思、我认为从技术上讲、可以通过确保"ethtool -K"来实现 HSR-TAG-ins-Offload 迷惑不解 "并保留其他一切 亮起  在  https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/latest/exports/docs/linux/HSR/Kernel/Network/HSR_Offload.html 中的 Foundational_Components 卸载设置脚本中 Kernel_Drivers。但是、这样做对整体卸载的影响不太清楚。  

    -道林

  • 0
    TI__Guru**** 2419530 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Daolin：

    Idiea 位于内核  https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/net/hsr/hsr_device.c 的 HSR 代码中

    在 Linux 内核中的这段 HSR 代码中、依赖于 HSR 卸载 照明器 、MTU 将为1494或1500... 我们可以在下一个通话中了解更多详细信息

  • 0
    TI__Guru**** 2419530 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Milan、  

    Unknown 说：
    在 Linux 内核中的此 HSR 代码中、取决于 HSR 卸载 照明器 、MTU 将为1494或1500... 我们可以查看下一个电话的详细信息
    Unknown 说：
    HSR 性能测试需要最大帧长度才能支持多达1528字节(14字节以太网标头+ 4字节 VLAN 标签+ 6字节 HSR 标签+ 1500字节 MTU + 4字节 FCS)

    对最大帧长度的这种描述似乎从1500B MTU 中排除了6B HSR 标签？ 我完全不理解 HSR 标签是计入1500B MTU 还是不应该是 MTU 的一部分...  

    [/报价]

    当然、如果您的优先级列表中目前不是很高、我们可以在下一次通话中对此进行更多讨论。

    -道林