[参考译文] TMS320C6457：NDK 库中的 SEND()函数

宫崎

回复：#1

当所有输入和输出缓冲器同时变为满状态时、会出现一个常规的 TCP 死锁问题。 下面是一个描述问题的链接。

如果没有足够频繁地调用 recv()，则可能会发生另一种情况。 在较低的层次上、PBM 资源在发送和接收之间共享。 如果未发生接收、则 PBM 池将耗尽、发送将阻止等待 PBM 资源变为可用状态。

回复：#2

最大 TCP 发送缓冲区大小为65535字节。

r3：#3

捕获 Wireshark 对问题的跟踪将非常有用。 请附加 Wireshark 日志文件。

此外、请尝试在 CCS 表达式视图中查看 TCP 统计数据变量。 在视图中输入名称"TCPs"。 在问题发生前后拍摄快照。

作为恢复机制、您可以向套接字添加5秒超时值。 如果 send()返回超时错误，则可以关闭并重新连接。

发送和接收套接字上的/* 5秒超时*/
timeout.tv_sec = 5；
timeout.tv_usec = 0；
setsockopt (s、SOL_socket、SO_SNDTIMEO、&timeout、sizeof (timeout))；
setsockopt (s、SOL_socket、SO_RCVTIMEO、超时、sizeof (timeout))；

~Ramsey

您好、Ramsey、

感谢您的评论和详细想法。 我与客户分享了这些信息。 我希望等待客户的反馈。

此致、Miyazaki

宫崎

我认为您需要在堆栈中启用一些调试消息。 《NDK 用户指南》第3.5节提供了一些有关调试应用的信息。 NDK 参考指南第2.5节介绍了有关 DbgPrintf() API 的一些信息。 最好在客户构建中启用此功能。 我将向您返回代码的仪器位置。

~Ramsey

宫崎

尝试检测以下函数：

/ti/ndk/stack/sock/sock.c：SockSend()
/ti/ndk/stack/tcp/tcpout.c：TcpOutput()
/ti/ndk/stack/ip/ipout.c：IPTxPacket()

一般执行流程是

SockSend ()->TcpOutput（)->IPTxPacket ()

将-DTCP_DEBUG 添加到构建选项中。

~Ramsey

您好、Ramsey、

感谢 您对此分析提供的有用建议。 我与我们的客户分享了您的意见并进行了讨论。 对于调试构建、由于行为不同、客户无法确认发生了此问题。 因此、我们假设很难通过一些调试消息来阐明此问题的根本原因...

然后，对于 SEND ()/recv ()的超时，客户添加了超时 并尝试验证此问题，但是，我听说 SEND ()没有返回超时错误。

从该视图的角度来看、

1.您是否会认为 PBM 池可能会耗尽 ？

2.当 PBM 池即将用完时，recv()是否也会阻止等待 PBM 资源变为可用？

请问您的专家对他们有什么建议/意见吗？

由于缺乏信息、客户了解很难对该问题进行分析。 不过、非常感谢您的建议。 在客户收到专家的意见后，客户计划关闭此主题，直到客户能够获得更多详细数据。

此致、

宫崎

宫崎

是的、PBM 池仍有可能已耗尽。

NDK 使用的 PBM 池是一个双链接的缓冲区列表。 可以在 CCS Expressions 视图中查看可用 PBM 池的大小。 在表达式视图中输入'PBMQ_free '。 然后展开该项目。 "Count"值指示池中可用的缓冲区数量。

当 SEND ()故障再次发生时，停止处理器并检查 PBMQ_free Count 值。 如果该值为零，则很可能是 SEND ()锁定的原因。

如果 PBM 池不为零，则仍有另一种可能性。 驱动程序还具有自己的 PBM 池。 如果这种情况不存在、这也会是一个问题。 最后、驱动程序 EMAC DMA 代码可能有一个缓冲区池。 如果这种情况不存在、它也可能会解释问题。 但是、用于 C6457的网络驱动程序不属于 NDK 团队。 您需要联系处理器团队以了解驱动程序的详细信息。

PBM 池运行的最可能原因是数据可用时应用程序没有调用 recv()。 最常见的实现方式是创建一个专用任务来接收数据。 此任务将在循环中调用 recv()。 这可确保使用传入数据、并将所有 PBM 缓冲区回收到池中。

如果 PBM 池为空，则询问 recv()是否会阻止。 是的、可以。 PBM 缓冲器与接收和发送数据路径共享。

客户是否收集了 TCP 统计数据？ 这也可以通过在 CCS Expressions 视图中输入'TCPs'来查看。

~Ramsey

您好 Ramsey、

感谢你的建议。 我同意了您的意见、并收到了有关此问题恢复的询问。

当发生 PBM 池块问题时，是否有任何恢复过程(硬件重置除外)？

正如我之前所说的，客户在 send()/ recv()中添加了超时，客户告诉我 send()没有返回超时错误，我的意思是，系统似乎仍处于冻结状态。 如果可能、客户希望了解其他恢复方法。 例如，在问题发生后，如果调用 recv()，您是否会考虑是否有可能解决此死锁？

很抱歉，如果您将共享其他恢复方法或您对此的评论，我们将不胜感激。

此致、

宫崎

您好、Ramsey、

感谢您的分享专家的评论。 非常感谢您的宝贵建议。 我将关闭此主题、直到客户能够获得更多详细数据。

此致、

宫崎