Support for External Jumbo Frames (RFD 689)#10472
Conversation
rcgoodfellow
changed the title
FelixMcFelix
left a comment
FelixMcFelix
left a comment
There was a problem hiding this comment.
Thanks Ry, I mainly have questions around the organisation of versioned types.
FelixMcFelix
left a comment
FelixMcFelix
left a comment
There was a problem hiding this comment.
Okay, the fixups look good to me! Thanks for making this work Ry.
We've still got the usual OPTE + maghemite merge and image train to get through, we should coordinate when we want to kick that off.
Ack. I'm going to rebase this and take it for another racklette lap and then we can start the dominoes if all goes well. |
|
During testing, I found that an Ubuntu 24.04 guest was receiving an MTU 1500 RA despite: RA solicitation: Manual editing of the route was required in guest. |
|
@sion42x Good catch; I've updated the OPTE branch to push this down to router advertisement generation. |
|
I've made modifications based on the latest review feedback, added additional testing and taken this for a lap on berlin. Things are still working as expected for the fleet and user level jumbo frame opt ins and their combinations. |
| /// take effect on the next instance restart. | ||
| #[serde(default)] | ||
| pub enable_jumbo_frames: Option<bool>, | ||
| pub enable_jumbo_frames: bool, |
There was a problem hiding this comment.
Do we still want this to be nullable? It seems like we could still make it respect the preexisting value if it was nullable in the arguments to the instance_reconfigure db query?
There was a problem hiding this comment.
(if we don't, that's totally fine, but I figured I'd mention it)
There was a problem hiding this comment.
See #10472 (comment) — we're not super consistent but where possible I've been trying to make these fields required on update bodies in order to eliminate the ambiguity about what happens when you leave them out.
No UI work, just supporting the API changes and plumbing the jumbo frames enable flag through updates. Will need to update this to a main commit once oxidecomputer/omicron#10472 goes in.
This was added to early networking / Nexus as a part of #10472; we need to keep pace with it until this project lands. --------- Co-authored-by: Levon Tarver <11586085+internet-diglett@users.noreply.github.com>
…ts (#10825) Two helios-publisher bugs in tools scripts, found while running them on my machine locally with a non-default publisher layout (on-nightly preferred for local illumos builds). install_builder_prerequisites.sh: `pkg list -F tsv` emits the publisher annotation "(publisher)" inside the tab-separated name field for packages from a non-preferred publisher. Parsing with default whitespace splitting shifted the version from $2 to $3, so the comparison saw "(helios)" and failed with "helios: unbound variable" under set -u. We now query the release field directly with `pkg list -Ho release` (buildomat runners are on helios3 now, so pkg is versioned new enough for -o), removing the annotation entirely. install_opte.sh: the override p5p install referenced `pkg://helios-dev/driver/network/opte`, but OPTE CI had already switched its p5p publisher from helios-dev to helios (oxidecomputer/opte#945) before the reference landed in #10472, so the pattern never matched any allowable packages. We now point at pkg://helios. We also needed to update this in relation to `releng dev-tools/releng/src/main.rs` and the override. CI and default-publisher setups (including buildomat) are unaffected by the prerequisite change, and the opte override path only runs when OPTE_COMMIT is set, which main never does.
6 participants
Implements the Omicron side of RFD 689.
Depends on:
A CLI/SDK build to drive this new functionality is here
Docs for this new feature are here
Some other fixes included here.
Testing
Lab Environment Performance
I've tested this on
berlin. When the fleet level jumbo flag is set and instances have opted into jumbo, they come up with an 8500 byte MTU in linux. The numbers I see for TCP fromberlinrunning through one of the externald4x4routers is.iperf3client)For UDP
I also tested that a pair of clients with and without jumbo enabled can communicate over both TCP and UDP.
Control Bits
The fleet-level jumbo enable and instance-level jumbo enable have been tested in combination. For an instance to have jumbo frames enabled, both the fleet level setting and the instance level setting must be set to true. I've tested all combinations of these settings with an instance restart in between changes to pick up the setting, and things behave as expected.