Skip to content

Carry jumbo frames as UMEM chains instead of oversized frames - #2

Merged
atoonk merged 1 commit into
mainfrom
fix-jumbo-multibuffer
Aug 10, 2026
Merged

Carry jumbo frames as UMEM chains instead of oversized frames#2
atoonk merged 1 commit into
mainfrom
fix-jumbo-multibuffer

Conversation

@atoonk

@atoonk atoonk commented Aug 10, 2026

Copy link
Copy Markdown
Owner

Fix Jumbo frames, actually use multi-buffer

  Any packet over 4100 bytes failed to start with a bare
  "XDP_UMEM_REG: invalid argument". frameSizeFor grew the UMEM frame to fit
  the largest packet, picking 8192 or 16384, but an aligned-chunk UMEM must
  satisfy 2048 <= chunk_size <= PAGE_SIZE and go-afxdp never sets
  XDP_UMEM_UNALIGNED_CHUNK_FLAG, so the kernel refused it.

  This is not architecture-specific, and it needed no unusual configuration:
  EC2 ships ENA at MTU 9001, and a receive-only run sizes frames as mtu + 18,
  so plain "--mode receive" on a stock instance was enough to hit it.

  Frames now stop at a page and packets larger than one span several, which
  is what go-afxdp's WithMultiBuffer has provided since v0.7.0. It engages on
  its own when the largest frame exceeds the frame size, so normal traffic
  keeps the single-frame path and its zero-copy generation untouched.

  Receive moves to ReceivePackets so a chain counts as one packet at its full
  length, with the protocol read from the fragment that carries the headers.
  Transmit keeps SendFunc, which writes straight into the UMEM frame but
  cannot chain; the jumbo path stages into a preallocated arena and lets
  SendBatch split it. Preflight reports chaining rather than refusing it, and
  now bounds the real limit, how many frames one packet may span.

  fleetKey gains the flag too: it is fixed at bind time, and the frame size
  does not imply it, since at 4096-byte frames a 4100-byte run chains nothing
  while a 9000-byte run chains.

  Verified on c7gn.xlarge (aarch64, AL2023, ENA 2.17.2g, MTU 9001), where the
  old binary reproduced the reported failure exactly: 9000-byte frames now run
  at 40 Gbit/s and 399,970 of 399,970 packets arrive. 64-byte and 1518-byte
  rates are unchanged.

  Closes #1
@atoonk
atoonk merged commit 067cf6b into main Aug 10, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant