Add tristate type for offload options (LP: #1956264)#270
Add tristate type for offload options (LP: #1956264)#270slyon merged 14 commits intocanonical:mainfrom
Conversation
|
At this point it seems that some tests are not run. I will check and update this PR. |
nicolasbock
force-pushed
the
tristate
branch
3 times, most recently
from
76586de to
199e060
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #270 +/- ##
=======================================
Coverage 99.06% 99.07%
=======================================
Files 61 61
Lines 11160 11196 +36
=======================================
+ Hits 11056 11092 +36
Misses 104 104 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@rlaager Could I get another review? Thanks! |
It looks good to me upon visual inspection. I haven't run the code. I probably should try to make time to do that, since I'm the one that wants this feature. :) |
|
Thanks fort he feedback @rlaager ! 😄 |
|
Would it help you if I made a package available for you? |
That would speed it up a bit, yes, as that saves me from patching the package and also guilts me into doing the testing right away. ;) Ideally, I'm looking for whatever is in 20.04 + this patch. But if it's a git snapshot or something that's probably fine too. I've got spare systems in the right state for quick testing, so it's pretty easy to run the test. |
|
TL;DR: The changes work as intended. There is a pre-existing issue applying link settings that is only documented for I tested today. I built the netplan from focal with this patch applied. Maybe that's not ideal from an upstream perspective (since I'm not building the commit on master), but that is what was easiest for me. My netplan config has this (among other things): That seems to build the correct output: It doesn't actually work: It's not an issue of Here we can see why: networkd refuses to apply 10-netplan-enp4s0.link because it is matching the renamed name. This is the same problem as documented in netplan for
That issue is not specific to |
slyon
changed the title
slyon
left a comment
slyon
left a comment
There was a problem hiding this comment.
Thank you very much for this improvement @nicolasbock and sorry for the late reply (I was out of office for a while).
Thanks for the testing @rlaager If I understand your comment correctly the code works as intended, but is affected by an udev/link matching issue, which can be worked around by matching on MAC address?!
The PR looks good to me overall! There is just one small spelling change (on/off -> true/false) that I'd like to push for; see inline comment. Furthermore, I'm wondering if this offload config is something that could be tested in an emulated (qemu/kvm) test environment and if so if it would make sense to add an integration test for it in tests/integration/ethernets.py? But it might need special offloading hardware (which is not available in qemu), right?
Also, running make check locally seems to fail for me, due to coverage issues, could you please rebase this branch to the latest main branch and double check that?
Correct.
Correct. The Specifically, in my case, these are Intel NICs using the ixgbe driver. On early boot, they are named
Now, I would probably argue that networkd should apply I'm pretty sure I tried matching on
Correct. networkd will apply the Now, in my particular case, the interfaces are being put into a bridge, so the MAC addresses get changed once they are added into the bridge. So in that particular configuration, even with the MAC address matching, the That's all suboptimal, but: 1) Setting this at boot is good enough for me. 2) This issue is about This is clearly a known issue, as the netplan documentation for So my suggestion was to either: A) duplicate that not to these settings, or B) make it more general somehow.
Yes, this can be tested in a qemu/kvm VM. With either a virtio or e1000e NIC, |
|
@slyon I addressed your inline comments. I am still working on the other issues. |
nicolasbock
force-pushed
the
tristate
branch
2 times, most recently
from
4148b08 to
5e7d22e
Compare
|
@slyon When trying to update the ubuntu@trusty-tamarin:~/pwd$ meson setup build --prefix=/usr
The Meson build system
Version: 0.53.2
Source dir: /home/ubuntu/pwd
Build dir: /home/ubuntu/pwd/build
Build type: native build
meson.build:1:0: ERROR: Meson version is 0.53.2 but project requires >= 0.61.0
A full log can be found at /home/ubuntu/pwd/build/meson-logs/meson-log.txtDo I need to install |
Don't worry about that too much. I can deal with the ABI definitions at the end. Focal packages are too old, so we're still using But you also need a newer version of |
Closes: https://bugs.launchpad.net/netplan/+bug/1956264 Signed-off-by: Nicolas Bock <nicolas.bock@canonical.com>
Signed-off-by: Nicolas Bock <nicolas.bock@canonical.com>
Signed-off-by: Nicolas Bock <nicolas.bock@canonical.com>
Signed-off-by: Nicolas Bock <nicolas.bock@canonical.com>
Signed-off-by: Nicolas Bock <nicolas.bock@canonical.com>
Signed-off-by: Nicolas Bock <nicolas.bock@canonical.com>
|
@slyon Would you like me to squash the commits in this PR? |
https://mesonbuild.com/Getting-meson.html Despite that Ubuntu 20.04 is frozen at an old version of Meson, you can manually install the latest version (because its only dependency is python 3.7) and use that for personal development albeit obviously not to build Ubuntu packages. |
Thanks for the information @eli-schwartz . I was just wondering within the context of the abi build instructions. Using |
| /* netplan-feature: eswitch-mode */ | ||
| char* embedded_switch_mode; | ||
| gboolean sriov_delay_virtual_functions_rebind; | ||
|
|
There was a problem hiding this comment.
What exactly is the ABI concern that's leading to adding all these _tristate fields? Specifically, is it size or contents that you're worried about?
If size, they seem to be the same size to me. Granted, I'm using a test program and not netplan's source itself. But if size is the only concern, we could check that with the real netplan code (on all supported archs if necessary).
If contents: an old consumer looking at these will interpret UNSET as if it was TRUE. But is that actually a problem in practice? First off, are there likely any external consumers of those fields? Second, if there are and they interpret UNSET as TRUE, is that actually a problem, given that these fields default to true in the kernel? Third, we don't seem to be concerned about how old consumers will interpret these, as the deprecated fields are no longer being set moving forward anyway.
There was a problem hiding this comment.
Nice! You're right. This is a special case where both size and content make sense using the new types as well as the old, and it does not shift the memory layout. In this case I guess we can just change the type of the previous fields.
Size: Both enum and gboolean reduce to integer, so they are of same size. Content: An old consumer looking at these will interpret UNSET as if it was TRUE, which is the kernel's default (=UNSET) value.
There was a problem hiding this comment.
Sorry, I took the liberty to push to your PR branch, in order to clean up a few things.
We do not need to squash the commits, as we'll do a squash-merge afterwards. Also, I've reverted the WakeOnLan= setting, because it is unrelated to this offloading PR and also the off value is special/explicit in this case and not your usual boolean (.c.f. https://systemd.network/systemd.link.html#WakeOnLan=)
As suggested by @rlaager the ABI compatibility is not actually broken by this change of gboolean to NetplanTristate as both use the size of an integer and are even value/content compatible, as NETPLAN_TRISTATE_UNSET defaults to the kernel value (TRUE). So we can avoid deprecating the old offloading fields. Thanks for this investigation!
Also, thanks for your example of using ethtool to get/set those values. I've used it to implement an integration tests, which will be run during autopkgtest inside a qemu/kvm VM and/or LXD container. I needed to add a small quirt to the CI workflow, in order to add ethtool as a test dependency. Truns out that those values (all but large-receive-offload) can be used on a veth device as well, which is what we're using inside the integration tests:
# ethtool -k eth42 | grep -v fixed
Features for eth42:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ip-generic: on
tx-checksum-sctp: on
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: on
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: on
tx-tcp-mangleid-segmentation: on
tx-tcp6-segmentation: on
generic-segmentation-offload: on
generic-receive-offload: on
Finally, I've added a udevadm test /sys/class/net/IFACE command inside the netplan apply CLI, to make it actually apply those changes at runtime without a reboot. I think this migh solve the issue described above, at least in some cases (it works inside the integration test).
@nicolasbock Let me know what you think! From my POV this PR is now ready to be merged!
Thanks again for your continued contributions to the netplan project! And also thanks to all the other people involved in reviewing this PR!
Using bond, bridge, and VLAN devices results in sharing MAC addresses across interfaces. Matching by MACAddress fails in two ways. It will overmatch by matching all the interfaces (physical and virtual) that share that MAC address. It will undermatch by no longer matching the physical interface once its MAC address has been changed. Matching by PermanentMACAddress fixes both of those issues. This replaces the old "workaround" of setting Type=!vlan bond bridge. That code had a comment saying, "something outputs netplan config that includes using the MAC of the first phy member of a bond as default value for the MAC of the bond device itself." I think this was a misunderstanding of what was going on there. In both examples, the configuration was attempting to match a physical interface by MAC address, not provide a MAC address to set on the virtual device. These are the two Launchpad bugs referenced by the code: https://bugs.launchpad.net/netplan/+bug/1804861 https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1888726 The comment continued, "This is evil, it's an optional field and networkd knows what to do if the MAC isn't specified". This configuration is perfectly reasonable. It is in fact required, as explained in the netplan documentation, if one wants to use settings that apply in the .link file (wakeonlan or the offload settings). This is because networkd refuses to apply a .link file that matches by name if the interface has already been renamed. At a minimum, this means that matching by MAC address is required if one wants to be able to change the settings after boot (on interfaces that are renamed). If the interfaces are renamed at early boot, before the netplan configuration applies, matching by MAC address is required for those settings to apply at all. For my example, see: #270 (comment) #270 (comment) Arguably, netplan should always use PermanentMACAddress, at least for physical interfaces. But that change might have unintended consequences, so I opted for the more minimal change of only using it in these complex scenarios (which are already special-cased). COMMITS: * Match by PermanentMACAddress in complex scenarios Using bond, bridge, and VLAN devices results in sharing MAC addresses across interfaces. Matching by MACAddress fails in two ways. It will overmatch by matching all the interfaces (physical and virtual) that share that MAC address. It will undermatch by no longer matching the physical interface once its MAC address has been changed. Matching by PermanentMACAddress fixes both of those issues. This replaces the old "workaround" of setting "Type=!vlan bond bridge". That code had a comment saying, "something outputs netplan config that includes using the MAC of the first phy member of a bond as default value for the MAC of the bond device itself." I think this was a misunderstanding of what was going on there. In both examples, the configuration was attempting to match a physical interface by MAC address, not provide a MAC address to set on the virtual device. The comment continued, "This is evil, it's an optional field and networkd knows what to do if the MAC isn't specified". This configuration is perfectly reasonable. It is in fact required, as explained in the netplan documentation, if one wants to use settings that apply in the .link file (wakeonlan or the offload settings). This is because networkd refuses to apply a .link file that matches by name if the interface has already been renamed. At a minimum, this means that matching by MAC address is required if one wants to be able to change the settings after boot (on interfaces that are renamed). If the interfaces are renamed at early boot, before the netplan configuration applies, matching by MAC address is required for those settings to apply at all. Arguably, netplan should always use PermanentMACAddress, at least for physical interfaces. But that change might have unintended consequences, so I opted for the more minimal change of only using it in these complex scenarios (which are already special-cased). * doc: update match.mac wrt permanent vs virtual MAC * networkd: apply PermanentMACAddress= to all MAC matches * test:integration:base: add veth MAC matching quirk --------- Co-authored-by: Lukas Märdian <slyon@ubuntu.com>
5 participants
Signed-off-by: Nicolas Bock nicolas.bock@canonical.com
Description
Checklist
make checksuccessfully.make check-coverage).