From ef94c93a0822beda2f8c691bd4390727f7355322 Mon Sep 17 00:00:00 2001 From: Martin Braun Date: Tue, 19 Oct 2021 18:09:31 +0200 Subject: mpmd: Increase UHD-side MTU cap for 10 GbE and 1 GbE This gets closer to what our hardware can actually support. See the comments for further explanations. This has the side-effect of patching an issue on X410 (using 200 MHz images) where garbage samples would get injected (one per packet). It is not, however, the final fix for that problem. --- mpm/python/usrp_mpm/discovery.py | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'mpm/python') diff --git a/mpm/python/usrp_mpm/discovery.py b/mpm/python/usrp_mpm/discovery.py index bae736150..c33f1e3c4 100644 --- a/mpm/python/usrp_mpm/discovery.py +++ b/mpm/python/usrp_mpm/discovery.py @@ -16,9 +16,9 @@ from usrp_mpm.mpmutils import to_binary_str RESPONSE_PREAMBLE = b"USRP-MPM" RESPONSE_SEP = b";" RESPONSE_CLAIMED_KEY = b"claimed" -# "Max MTU" is not a redundant name. We don't know the total path MTU, but we -# can say for sure that it won't exceed a certain value, and that's the max MTU -MAX_MTU = 8000 +# A buffer size large enough to capture any UDP packet we receive on the +# discovery socket +MAX_SOCK_BUFSIZ = 9000 # For setsockopt IP_MTU_DISCOVER = 10 IP_PMTUDISC_DO = 2 @@ -71,7 +71,7 @@ def _discovery_process(state, discovery_addr): try: while True: - data, sender = sock.recvfrom(MAX_MTU) + data, sender = sock.recvfrom(MAX_SOCK_BUFSIZ) log.debug("Got poked by: %s", sender[0]) # TODO this is still part of the awful subnet identification if not sender[0].startswith(discovery_addr_prefix): -- cgit v1.2.3