pespin submitted this change.
gsmtap_util: Increase source_fd's SO_SNDBUF to 4MB
Using bpftrace we spotted osmo-bts sporadically blocking on send()
of gsmtap_log for 2-4s, most probably due to the UDP send buffer being
full. The wmem_default of ~292KB is indeed a bit tight, and for instance
upstream Linux got its wmem_max to 4MB in april 2025 since it's becoming
more usual that sockets need to increase this value.
Hence, increase the SO_SNDBUF to 4MB to get some extra room and avoid
blocks (or drops if socket is later on set non-blocking) and be able to
accomodate to logging spikes better.
The kernel will take care of lowering the size set to the configured
net.core.wmem_max if needed.
Related: OS#6794
Change-Id: I5033a018dfc748b309600102b8a9ade0df014615
---
M src/core/gsmtap_util.c
1 file changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/core/gsmtap_util.c b/src/core/gsmtap_util.c
index 0a920e3..b46f273 100644
--- a/src/core/gsmtap_util.c
+++ b/src/core/gsmtap_util.c
@@ -528,6 +528,16 @@
buflen = 0;
setsockopt(gti->source_fd, SOL_SOCKET, SO_RCVBUF, &buflen, sizeof(buflen));
+ /* The wmem_default of 212992B is too low for heavy bursty gsmtap transmission (eg. tons of DEBUG logging).
+ * A full UDP socket send buffer can cause blocks (or drops if sk is later configured non-blocking),
+ * so let's try to increase it to a safer value of 4MB (newer default net.core.wmem_max in linux kernel since
+ * 2025 a6d4f25888b83b8300aef28d9ee22765c1cc9b34).
+ * The kernel will trim the size set to the configured net.core.wmem_max if lower.
+ * In case you wonder, YES! blocking of 2-4s was seen in osmo-bts gsmtap_log's send() during ttcn3-bts-test execution.
+ */
+ buflen = 4194304; /* 4 << 20 */
+ setsockopt(fd, SOL_SOCKET, SO_SNDBUF, &buflen, sizeof(buflen));
+
return gti;
err_cleanup:
To view, visit change 41716. To unsubscribe, or for help writing mail filters, visit settings.