system/NetworkManager
system/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager synced 2024-07-21 18:24:49 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

TODO: remove bridging/bonding and InfiniBand

Browse source 
Bonding and InfiniBand are done. Bridging isn't, but after removing
the bonding and generic infrstructure parts of that section, there
wasn't really enough left to be worth keeping.
This commit is contained in:
Dan Winship 2012-03-22 15:50:43 -04:00
parent 49105f7115
commit a44effc1c7
1 changed files with 0 additions and 125 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

125
TODO
View file

@ -432,63 +432,6 @@ that handle different system proxy handlers. Some of the proxy handlers are:
GNOME/KDE: how do these desktop environments retrieve proxy configuration?
* Bridging and Bonding Support
The largest complication here is that NetworkManager normally operates on
physical interfaces, while bridging and bonding involve tying multiple physical
interfaces together into a logical interface. This has interesting implications
for the D-Bus API and the NM device model. The first complication is that
we may need to do 802.1x port authentication on an interface before it can
communicate with the other side of the link, and those credentials may be
different for each interface; thus we may need to do separate 802.1x
operations on each interface that is part of a bridge/bond before adding each
one to the master bridge/bond interface.
In this way bridge/bond interfaces may be treated the same way as NetworkManager
treats VPN interfaces already; one or more physical interface NMConnections must
be activated before the master bridge/bond interface's NMConnection can be
activated, though this all happens internally.
To enable bridging and bonding in the NMConnection itself, we should create
new NMSettingBridge and NMSettingBond classes that contain information specific
to each. Both settings would contain a 'components' property with an
'array of string' type which would contain the UUIDs of the Connections of
physical interfaces that compose the bridge or bond. Thus NetworkManager would
have the necessary information to tie lower-level interface configuration
(802.1x, MTU, MAC address locking, duplex mode, speed, etc) to each physical
interface that will be part of the bridge/bond, configure the interface with
it, and then configure the master bridge/bond interface at upper layers using
configuration specific for the bridge/bond interface (like IP details). Thus
for a single active bridge, two or more NMConnections would be activated; one
for each physical interface component of the bridge/bond, and one for the master
bridge/bond interface itself.
NMSettingBridge would contain at least the following keys:
components: (array of string) UUIDs of component connections
stp: (boolean) on to enable STP, off to disable
NMSettingBond would contain at least the following keys:
components: (array of string) UUIDs of component connections
mode: (string) one of "balance-rr", "active-backup", "balance-xor",
"broadcast", "802.3ad", "balance-tlb", or "balance-alb"
monitor-interval: (uint) Specifies link monitoring interval (in milliseconds);
NM will always enable netlink carrier monitoring if this
value is non-zero so this property only affects speed and
duplex checking
In the future we may consider adding other bonding parameters like "up-delay"
and "down-delay".
Then we'd add a 'component' (boolean) property to NMSettingConnection to
indicate that the component interface connections were in fact components of
a bridge or bond and shouldn't be automatically started by NetworkManager or
displayed as separate connections in the user interface.
TO BE CONTINUED
* Better Tablet/Mobile Behavior
There are a few components to this:
@ -539,71 +482,3 @@ Consequently the same behavior should be used when a better connection becomes
available. This behavior should be suspended when special connections like
Internet Connection Sharing ones are started, where clearly the priorities
are different (ie, for Mobile Hotspot 3G > WiFi).
* IP over Infiniband (IPoIB)
These interfaces are similar to Ethernet interfaces with a few distinct
differences:
1) they have 64-bit MAC addresses (GUIDs in Infiniband parlance)
2) DHCP clients need to be modified to handle IPoIB
3) they have a different ARP type and different L2 options
By default the interfaces do not have IP capability, but they gain that
capability when certain kernel modules (ib_ipoib.ko) are loaded, which causes
the IP-capable interface is created. The IP-capable interfaces apparently have
ARPHRD_INFINIBAND set, which is likely what NM should use to identify them.
One outstanding question is whether NM should (a) detect all Infiniband
interfaces and load ib_ipoib.ko only when there is a defined NMConnection for
an Infiniband interface, or (b) whether NM should automatically load ib_ipoib.ko
for every Infiniband interface, or (c) whether NM should only manage Infiniband
interfaces that already have associated IP-capable interfaces (ie, something
else is responsible for loading ib_ipoib.ko). Depending on our implementation,
(a) might not be possible, because if IPoIB connections are treated similar to
plain Ethernet connections, we may not have any information about whether a
specific NMConnection is Infiniband other than the MAC address.
It turns out that on some distros other components (like system services) may
load ib_ipoib.ko for us. For exmaple, the 'rdma' package on Fedora/RHEL systems
contains /etc/rc.d/init.d/rdma which uses values in /etc/rdma/rdma.conf to load
ib_ipoib.ko at system startup if the user has requested it via IPOIB_LOAD=yes.
For the time being, if the some other component of the system loads IP for us,
NetworkManager should probably still recognize the Infiniband interface, but
leave it in unmanaged mode if there is no available IPoIB interface associated
with the Infiniband one. i.e. for now, NM should not automatically load
ib_ipoib.ko.
The second question is whether to fold IPoIB support into the NMDeviceEthernet
class as was done for s390 network interfaces, or whether to create a subclass
of NMDevice:
1) extend NMDeviceEthernet: this would involve loosening the assumption that
hardware addresses (the 'hw-address'/'perm-hw-address' properties of
NMDeviceEthernet and the 'mac-address'/'cloned-mac-address' properties of
NMSettingWired) are 48 bits wide and instead can be either 48 or 64 bits wide.
2) create a new NMDevice subclass for Infiniband devices tailored to Infiniband
specific behavior and attributes. This would be a lot more code since we'd have
to duplicate much of what NMDeviceEthernet already does, plus add the
Infiniband device class to libnm-glib. This also would be the least invasive
from an API standpoint since the existing API would be unchanged, except for
the addition of a new value in the NMDeviceType enum, which clients should
ignore if they don't understand it. (Need to coordinate additions to this enum
between 0.8.x and 0.9.x since 0.9.x has more device types, but we want to make
sure new device types get the same number for both branches).
For Infiniband specific options we could either fold them into NMSettingEthernet
or create a new NMSettingInfiniband class. Current Infiniband specific options
are partitions/P_Keys, datagram vs. connected mode, and MTU. The default MTU
varies with the 'mode'; for datagram it is currently 2044, while for connected
mode it is currently 65520. Given that we only have 2 IB-specific options
we should probably just fold them into NMSettingEthernet similar to what was
done for s390-specific options.
For some general (and also Red Hat/Fedora specific) information see:
http://tools.ietf.org/html/rfc4392
http://rhkernel.org/#RHEL6+2.6.32-71.18.2.el6/Documentation/infiniband/ipoib.txt