Set OPTE maximum port MTU during creation#984
Draft
FelixMcFelix wants to merge 2 commits intomasterfrom
Draft
Conversation
This allows opteadm/sled-agent to define what the maximum MTU on a link will be on a per-port basis, which should be governed by some sense of control plane policy. I think that create-time is really the only time we can do this: assignment of max MTU (SDU in MAC parlance) happens as part of the call to `mac_register`, and in turn communication of MTU to a guest by viona is basically in a write-once register in the config space. I think all that seems to need checking is that this is visible off the bat to viona via propolis, and that visibility holds whether or not the propolis is in a non-global zone. Also closes #767.
Collaborator
Author
|
Testing notes from falcon using pfexec opteadm set-xde-underlay igb0 igb1
pfexec opteadm create-xde --guest-mac a8:40:25:ff:00:01 --private-ip 10.0.0.1 --vpc-subnet 10.0.0.0/24 --gateway-mac a8:40:25:00:00:01 --gateway-ip 10.0.0.254 --vpc-vni 1701 --src-underlay-addr fd44::01 --mtu 8500 opte0
pfexec opteadm create-xde --guest-mac a8:40:25:ff:00:02 --private-ip 10.0.0.2 --vpc-subnet 10.0.0.0/24 --gateway-mac a8:40:25:00:00:02 --gateway-ip 10.0.0.254 --vpc-vni 1701 --src-underlay-addr fd44::01 --mtu 8500 opte1
pfexec opteadm add-router-entry -p opte0 10.0.0.0/24 sub4=10.0.0.0/24 system
pfexec opteadm add-router-entry -p opte1 10.0.0.0/24 sub4=10.0.0.0/24 system
pfexec opteadm add-fw-rule -p opte0 --dir in --action allow --priority 0 --hosts any --protocol any --ports any
pfexec opteadm add-fw-rule -p opte1 --dir in --action allow --priority 0 --hosts any --protocol any --ports anyI modified the Launching the guests, we see on each: piano login: root
Linux piano 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue May 5 10:40:06 UTC 2026 on ttyS0
root@piano:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8500 qdisc mq state UP group default qlen 1000
link/ether a8:40:25:ff:00:02 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.2/32 brd 10.0.0.2 scope global dynamic enp0s6
valid_lft 86335sec preferred_lft 86335sec
inet6 fe80::aa40:25ff:feff:2/64 scope link
valid_lft forever preferred_lft foreverroot@violin:~# dladm
LINK CLASS MTU STATE BRIDGE OVER
vioif0 phys 1500 up -- --
root@violin:~# dladm show-linkprop -pmtu
LINK PROPERTY PERM VALUE DEFAULT POSSIBLE
vioif0 mtu rw 1500 1500 60-8500Slightly different default behaviour (Linux goes straight to max MTU, illumos sticks at 1500), but otherwise it is visible to the guest. Now to check for propolis in a zone. |
Collaborator
Author
From testing on standalone omicron, it would appear to work just fine! Kernel 6.18.7-0-virt on x86_64 (/dev/ttyS0)
localhost login: root
Welcome to Alpine!
The Alpine Wiki contains a large amount of how-to guides and general
information about administrating Alpine systems.
See <https://wiki.alpinelinux.org/>.
You can setup the system with the command: setup-alpine
You may change this message by editing /etc/motd.
localhost:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8500 qdisc mq state UP qlen 1000
link/ether a8:40:25:f0:00:00 brd ff:ff:ff:ff:ff:ff
inet 172.30.0.5/32 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::aa40:25ff:fef0:0/64 scope link
valid_lft forever preferred_lft foreverIn this case I've modified |
This is necessary, but CI won't catch it as these types are not part of `opte_api`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This allows opteadm/sled-agent to define what the maximum MTU on a link will be on a per-port basis, which should be governed by some sense of control plane policy. I think that create-time is really the only time we can do this: assignment of max MTU (SDU in MAC parlance) happens as part of the call to
mac_register, and in turn communication of MTU to a guest by viona is basically in a write-once register in the config space.I think all that seems to need checking is that this is visible off the bat to viona via propolis, and that visibility holds whether or not the propolis is in a non-global zone.
Also closes #767.