the problem with this is, that ethtool options are (AFAIK) not exposed via netlink. That means, NetworkManager gets no notification when the value changes. So, to expose the property on D-Bus, NetworkManager can only poll for the value (either periodically, or once during activation of the profile).

Also note, that while the feature might be interesting, there is already the ethtool kernel API which exposes this setting. So, exposing this on D-Bus is only slightly better then just querying ethtool.

The advantage of providing this settings via Network Manager is that it leads to a uniform API to get network settings, namely via Network Manager, instead of having to figure out that some settings can be obtained via Network Manager but others cannot (for example speed is available via dev.get_speed(). Also it seems that Network Manger already contains the code to get the ethtool settings:

src/devices/nm-device-ethernet.c:
nm_platform_ethtool_get_link_settings (NMPlatform *self, int ifindex, gboolean *out_autoneg, guint32 *out_speed,  NMPlatformLinkDuplexType *out_duplex)

but there is only one method that uses the out_speed to store it as a device property instead of also storing autoneg and duplex.

src/devices/nm-device-ethernet.c:
link_speed_update (NMDevice *device)
[...]
if (!nm_platform_ethtool_get_link_settings (nm_device_get_platform (device), nm_device_get_ifindex (device), NULL, &speed, NULL))

Not sure, when link_speed_update() is called but if it could be changed to link_update() and then just store duplex and autoneg settings, too, it would be great.

About polling, isn't it enough to poll the settings once it creates a device object to return via dBus? There is no need to update the state internally when nobody asks AFAICS.

Another scenario came up that makes this more important: There is interest to run nmstate in a container to manage networking on the host by mounting the dbus socket into the container. To support this fully, everything would need to be done via NetworkManager since running ethtool in the container would report the wrong data.

Mass-moving bugs RHEL <= 7.6.0 to 7.7.0.
As we are past RFE deadline for 7.7.0 and we should have no new features on 7.8.0, please evaluate if it's still wanted on RHEL7 and contact PM for exception. You may also move it to RHEL8 if that's wanted. Thanks!

Seems to me like this RFE should be targetted to RHEL 8.X.
Is there a clone of this with a different target?

Reassigned.

Since Nmstate is using Nispor for this, this can be closed.