expose layer2, hwchecksumming, buffer_count network-hardware options

[Christian Ehrhardt ]

Some network HW configurations like wake-on-lan, mtu and such are already exposed.
Certainly not all that ethtool can handle, and none of the attributes that not even ethtool can handle.

In the System z world there are a few HW attributes that are rather common to be changed.
In particular:
- layer2 (required to be set correctly for networking to work at all)
- hwchecksumming (performance)
- buffer_count (performance)

Look at chzdev of package s390-tools for more background and how it is currently done via udev rules.

For s390x - If implemented IBM would have to work with us in a way that the passing of the ephemeral state netplan provides to a system later on that gets (re-)configured via chzdev works as expected.
But I guess for now the bug is for the "lower network-HW options" in general and not only s390x.

[Martin Pitt (pitti)]

A bug report about "lower network-hw options" in general is too unspecific -- let's keep this for the three ones you mentioned, and please file separate bugs for other properties that we need to change. I don't have access to a z series system (other than one production instance where I cannot configure networking), how are these configured and documented?

[Christian Ehrhardt  (paelzer)]

Yeah you are right - thanks for making it more specific in the title.

Xnox response is probably heading towards the right (then again more generic) direction, quoting from there until he chimes in here:

"For a while I have been pondering to have a few s390x specific keys in
cloud-init / MaaS, e.g.:

chzdev_enable:
 - [600,1.0.0400]

cio_ignore:
 - [all]

Or some such. (chzdev creates additional rules to remove devices from
kernel ignore list too). But one should be able to pass arbitrary
key-value pairs too because One would do things like these too:

chzdev_enable:
  - 600:
    portno: 1
    level2: 0

To tweak various things in sysfs, via chzdev udev rules generator.

This is all s390x specific, for the OSA cards configuration as seen on
LPAR & z/VM (~= bare metal configurations)"

[Launchpad Janitor (janitor)]

[Expired for nplan (Ubuntu) because there has been no activity for 60 days.]

[Christian Ehrhardt  (paelzer)]

While wishlist priority, reopening until we really "decided" to drop it.

Let me know if you still wait on something like further examples or such, otherwise I'd keep it around until implemented or explicitly dropped.

[Martin Pitt (pitti)]

I kept it as incomplete as "To tweak various things in sysfs, via chzdev udev rules generator" is way too unspecific -- you are of course invited and welcome to add this support yourself (happy to review patches), but I cannot start implementing this on my side without a precise description of what should be added.

Also, note that netplan's primary design is to punt the actual work to networkd or NetworkManager, and it shouldn't actually grow functionality by itself. It's fine to generate a couple of extra udev rules or sysctl.d/ files, but the thing that it *definitively* cannot do is to actually write/change things in /sys, /dev, or devices by itself.

[Christian Ehrhardt  (paelzer)]

Hi Martin,
thanks for explaining - I think the most important point I missed to consider before is:
"Also, note that netplan's primary design is to punt the actual work to networkd or NetworkManager"

If they have such functionality in NetworkManager/networkd it will be taken care of.
I'm not sure if there would be work to expose more in Netplan to instruct networkd to do so properly. But I didn't work to much with networkd on s390 up to now. So I'd leave that to IBM to tell us.

I'll keep the bug on incomplete and send the bug link to their networking people for consideration.

[Launchpad Janitor (janitor)]

[Expired for nplan (Ubuntu) because there has been no activity for 60 days.]