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.

1 files changed, 14 insertions, 4 deletions

diff --git a/host/lib/usrp/mpmd/mpmd_link_if_ctrl_udp.cpp b/host/lib/usrp/mpmd/mpmd_link_if_ctrl_udp.cpp
index 89f713f1e..fe7d2b670 100644
--- a/host/lib/usrp/mpmd/mpmd_link_if_ctrl_udp.cpp
+++ b/host/lib/usrp/mpmd/mpmd_link_if_ctrl_udp.cpp
@@ -29,14 +29,24 @@ using namespace uhd::mpmd::xport;
 
 namespace {
 
-//! Maximum CHDR packet size in bytes
-const size_t MPMD_10GE_DATA_FRAME_MAX_SIZE    = 7972;
-const size_t MPMD_1GE_DATA_FRAME_MAX_SIZE     = 1472;
+//! Maximum CHDR packet size in bytes.
+// Our 10GbE connections use custom FPGA code which caps frames at 8192 bytes.
+// However, we artificially limit this to a smaller frame size, which gives us
+// a safety margin.
+const size_t MPMD_10GE_DATA_FRAME_MAX_SIZE = 8016;
+// For 1 GbE, we either go through our on-chip PHY/MAC, which also caps at 8192
+// bytes, or we go through the RJ45, and then the DMA to the chip, which can go
+// higher. We thus choose the same value as for 10 GbE.
+// Note that for 1 GbE, we almost always have an MTU of 1500, so we will rarely
+// meet this frame size, but MTU discovery will take care of that. This is just
+// a cap to make sure we never try CHDR packets that will clog our fabric.
+const size_t MPMD_1GE_DATA_FRAME_MAX_SIZE = 8016;
 
 //! Number of send/recv frames
 const size_t MPMD_ETH_NUM_FRAMES = 32;
 
-//!
+//! Buffer depth in seconds. We use the link rate to determine how large buffers
+// must be to store this many seconds worth of data.
 const double MPMD_BUFFER_DEPTH = 20.0e-3; // s
 //! For MTU discovery, the time we wait for a packet before calling it
 // oversized (seconds).