summaryrefslogtreecommitdiff
path: root/TODO
diff options
context:
space:
mode:
authorDan Williams <dcbw@redhat.com>2011-09-07 18:54:16 -0500
committerDan Williams <dcbw@redhat.com>2011-09-07 18:54:16 -0500
commit80a8b6fabfa8ae3222844abdbe6bf69509ce0132 (patch)
treea650a75b5efcf8849a084dc4cb3a682452db97c5 /TODO
parent3d898d1b66eeecc550abf1d83fefc0dff6dcf0bd (diff)
downloadNetworkManager-80a8b6fabfa8ae3222844abdbe6bf69509ce0132.tar.gz
todo: update TODO for IP over Infiniband
Diffstat (limited to 'TODO')
-rw-r--r--TODO53
1 files changed, 52 insertions, 1 deletions
diff --git a/TODO b/TODO
index 5234bd92ce..bc212751aa 100644
--- a/TODO
+++ b/TODO
@@ -549,4 +549,55 @@ 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.
+
+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.
+Any Infiniband-specific options (partitions, datagram vs. connected modes, etc)
+would need to be evaluated and then possibly added to NMSettingWired similar to
+what was done for s390.
+
+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 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
+
+