request for guidance on implementing VLAN reapplication in NetworkManager

Beniamino Galvani bgalvani at redhat.com
Thu Jun 6 13:42:12 UTC 2024


On Thu, Jun 06, 2024 at 01:41:20PM +0200, Oleksij Rempel wrote:
> Hello devs,
> 
> My name is Oleksij Rempel, and I am a Linux kernel developer primarily
> focused on network switch drivers. I have been evaluating various
> options for managing switch and bridge configurations, and
> NetworkManager appears to be the best fit for our requirements.

Hi,

good to hear that!

> However,
> there is still some work to be done. One of the missing features is the
> ability to reapply certain settings without interrupting the data flow.
> For instance, the ability to reapply `bridge-port.vlans` for slave ports
> is currently lacking.
> 
> As I am new to the NetworkManager code base and its architecture, I
> would like to ensure that I am on the right path. To better illustrate
> my use case, here is a script that demonstrates the desired
> functionality:
> 
> ```bash
> [...] 
> # Reapply VLAN settings on veth1-slave and check if changes are
> # reflected
> bridge v
> nmcli connection modify veth1-slave bridge-port.vlans "1002,1003 untagged"
> nmcli dev reapply veth1
> bridge v
> ```
> 
> If I understand the NetworkManager code correctly, the bridge master is
> handled by `nm-device-bridge.c`, while the slave interfaces are handled
> by `nm-device.c`.

A bridge device is always an instance of NMDeviceBridge. A device that
is a port of the bridge can be of different types and so it can be
e.g. a NMDeviceEthernet, a NMDeviceVlan, a NMDeviceBond, etc,; what
distinguishes a bridge port is that is has a NMDeviceBridge as
controller (master).

Your statement "slave interfaces are handled by `nm-device.c`" can be
correct or not depending on the interpretation. Generally, a bond port
is handled by the implementation of that specific device
(NMDeviceEthernet for ethernet devices, etc), with a fall back to the
super-class (NMDevice).

If we speak about setting the bridge VLANs on the port, that is
handled by NMDeviceBridge in attach_port(): when a port is attached to
the bridge, NM reads the "bridge-port.vlans" property of the port and
sets the needed VLANs on it via
nm_platform_link_set_bridge_vlans(on_master=TRUE).

> At this point, I am not entirely sure whether it is a
> good idea to reapply settings only on the slave interface separately, or
> if I need to do this from the master down to the slave interfaces.

I think it should be allowed (and it's useful) to update bridge VLANs
on the port independently of the bridge itself.

> Should I introduce a function to iterate and reapply all slaves on the
> master/controller side? Or should I not worry too much and handle
> differences only on the slave side if possible?
> 
> I would greatly appreciate any guidance or recommendations on the best
> approach to achieve this functionality.

I think what is missing is:

 - can_reapply_change()	in NMDevice needs to accept changes to the
   "vlans" property of NMSettingBridgePort;

 - check_and_reapply_connection() in NMDevice needs to detect when the
   bridge VLANs changed, via:

   nm_g_hash_table_contains_any(
      nm_g_hash_table_lookup(diffs, NM_SETTING_BRIDGE_PORT_SETTING_NAME),
      NM_SETTING_BRIDGE_PORT_VLANS)

   and if so, reapply the VLANs.

 - to reapply them, it needs to construct the list of platform VLANs
   similarly to setting_vlans_to_platform() and then set them via
   nm_platform_link_set_bridge_vlans(on_master=TRUE).  The best way to
   do that is probably to move the code that builds the VLANs to a
   common file (nm-device-utils.c) so that it can be called both by
   NMDevice and NMDeviceBridge.

Beniamino
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/networkmanager/attachments/20240606/39afbf60/attachment.sig>


More information about the Networkmanager mailing list