Allow user to specify order of network interfaces inside application

Currently, when application has both virtual network interfaces
configured and some network devices directly assigned, EVE will first
attach virtual interfaces in the order that follows ACL IDs (a historical
workaround for missing interface order field), followed by directly assigned
network adapters, in the order of the AppInstanceConfig.adapters
list.
To allow the user to specify the order between all application
network interfaces (across both virtual and passthrough devices), we
introduce a new boolean flag enforce_network_interface_order inside the
application instance config and allow the controller to pass the order
requirements for all application network adapters.
For backward compatibility reasons, by default this will be disabled
and the original ordering method will remain in use.

Signed-off-by: Milan Lenco <[email protected]>

proto/config/devcommon.proto

@@ -50,6 +50,26 @@ message Adapter {
   org.lfedge.eve.common.PhyIoType type = 1;
   string name = 2;  // Short hand name such as "com" from bundle
   EthVF eth_vf = 3; // Only relevant for PHY_IO_TYPE_PHY_IO_NET_ETH_VF
+
+  // Define the network interface order relative to other directly assigned
+  // network devices and virtual network adapters.
+  // Only applies to (assignable) network adapters, i.e. types: "PhyIoNetEth", "PhyIoNetWLAN",
+  // "PhyIoNetWWAN" and "PhyIoNetEthVF".
+  // The numbering is across both the "Adapter" (direct assignments) and the "NetworkAdapter"
+  // (virtual interfaces) lists for a given "AppInstanceConfig", thus every entry in these
+  // lists, excluding non-networking adapters, must have a unique order number
+  // (when the "enforce_network_interface_order" is enabled, see "VmConfig").
+  // Interface with a lower order value should appear inside the application before
+  // interface with a higher order value.
+  // The implementation of this ordering may depend on the hypervisor. For example,
+  // the hypervisor might virtualize the PCI bus and assign lower PCI addresses to
+  // interfaces with lower order values. But the actual outcome of interface ordering
+  // depends on the application and EVE therefore cannot guarantee desired order.
+  // Since this field was introduced in later versions, older EVE versions do not support
+  // user-defined interface ordering. For backward compatibility, the user-defined
+  // order is applied only if "enforce_network_interface_order" is enabled for the given
+  // application (see "VmConfig", file "vm.proto").
+  uint32 interface_order = 4;
 }
 
 // Information regarding Virtual Function (VF) customisation

proto/config/netconfig.proto

@@ -70,6 +70,24 @@ message NetworkAdapter {
   // allow AppInstance to discover other AppInstances
   // attached to this network instance. Default is false
   bool allow_to_discover = 42;
+
+  // Define the network interface order relative to other virtual network adapters
+  // and directly assigned network devices.
+  // The numbering is across both the "Adapter" (direct assignments) and the "NetworkAdapter"
+  // (virtual interfaces) lists for a given "AppInstanceConfig", thus every entry in these
+  // lists, excluding non-networking adapters, must have a unique order number
+  // (when the "enforce_network_interface_order" is enabled, see "VmConfig").
+  // Interface with a lower order value should appear inside the application before
+  // interface with a higher order value.
+  // The implementation of this ordering may depend on the hypervisor. For example,
+  // the hypervisor might virtualize the PCI bus and assign lower PCI addresses to
+  // interfaces with lower order values. But the actual outcome of interface ordering
+  // depends on the application and EVE therefore cannot guarantee desired order.
+  // Since this field was introduced in later versions, older EVE versions do not support
+  // user-defined interface ordering. For backward compatibility, the user-defined
+  // order is applied only if "enforce_network_interface_order" is enabled for the given
+  // application (see "VmConfig", file "vm.proto").
+  uint32 interface_order = 50;
 }
 
 message WirelessConfig {

proto/config/vm.proto

@@ -80,4 +80,16 @@ message VmConfig {
   bool enable_vnc_shim_vm = 22;
   // Boot mode: Legacy or UEFI
   VmBootMode boot_mode = 23;
+  // Enables enforcement of user-defined ordering for network interfaces.
+  // This applies to both virtual interfaces (specified in the "AppInstanceConfig.interfaces" list)
+  // and directly assigned network adapters (specified in the "AppInstanceConfig.adapters" list
+  // as items of type "PhyIoNetEth", "PhyIoNetWLAN", "PhyIoNetWWAN", and "PhyIoNetEthVF").
+  // Note: Older versions of EVE may not support enforcing the user-defined order
+  // of application network interfaces. The controller can check
+  // "ZInfoDevice.api_capability" to verify if the configured device supports the
+  // API capability "API_CAPABILITY_ENFORCED_NET_INTERFACE_ORDER".
+  // Please beware that EVE's ability to influence the order of VM application interfaces
+  // is limited. Depending on the application's operating system, achieving the desired network
+  // interface order might not be possible.
+  bool enforce_network_interface_order = 24;
 }

proto/info/info.proto

@@ -677,6 +677,7 @@ enum APICapability {
   API_CAPABILITY_BOOT_MODE = 7; // Support different boot modes for Edge Applications (VMs)
   API_CAPABILITY_MTU = 8; // Allows to set MTU for network adapters and network instances
   API_CAPABILITY_ADAPTER_USER_LABELS = 9; // Supports user-defined shared network adapter labels
+  API_CAPABILITY_ENFORCED_NET_INTERFACE_ORDER = 10; // EVE is able to enforce the user-defined order of application network interfaces
   // Add new values as new EdgeDevConfig API features are implemented
 }