我知道net.core.wmem_max的{{1}}参数控制着我可以通过sysctl请求的最大套接字缓冲区大小。但是，我遇到了一个更基本的限制。我的情况摘要：
我有一个设备正在尝试以高速率发送UDP数据报。该设备和我的NIC支持以太网流控制，因此当它不能再接受任何数据以限制流的速率时，它可以与我的系统进行通信。这样就可以做到，这样我的应用程序就可以将数据尽可能快地推送到套接字中，并且在发送缓冲区已满时，对setsockopt()的调用应该阻塞，直到有空间将数据报排队为止。
在某种程度上，这可以按预期进行；系统（通过send()，GNOME系统监视器等）报告总的出站网络流量平均而言是预期的速率。但是，我注意到的是，根据我请求的缓冲区大小，我可能会也可能不会获得期望的背压。
在所有测试中，我都设置了netstat（100 MB）。我正在运行Ubuntu 18.04。根据我通过net.core_wmem_max = 100000000通过setsockopt()请求的发送缓冲区大小，我注意到了两种操作方式：
大小= 10 MB：在这种情况下，测试正常进行；一旦套接字发送缓冲区达到其限制，SO_SNDBUF就会按预期阻塞。
大小= 100 MB：在这种情况下，我看到了通过send()输出到网络的所需速率，但是如果我将其与我的数据量进行比较通过netstat进入套接字，很明显一些数据正在丢失。例如，我的网络数据速率可能为640 MB /秒，但是如果我总结对send()的所有成功调用的返回值，则实际上是将800 MB /秒推入套接字。我正在对所有send()调用进行错误检查，以确保它们均未失败。
如果我使用send()来监视发送缓冲区的大小（通过/proc/net/udp列），则表明发送缓冲区的大小只能达到32 MB，并且永远不会更大。这意味着发送队列长度有一些基本限制，但是由于它从未达到配置的100 MB容量，因此tx_queue不会阻塞，而是将数据扔到地板上。 send()的手册页暗示了这种可能性：
send()
但是，我找不到有关哪种情况可能导致数据包被静默丢弃的权威信息。似乎我不能相信我请求的发送缓冲区容量，那么Linux中套接字发送缓冲区的最大有效大小是多少？