After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 677150 - network: make sure ipoib is handled
network: make sure ipoib is handled
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: network-indicator
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks: 677144 677152
 
 
Reported: 2012-05-31 01:44 UTC by Matthias Clasen
Modified: 2012-12-17 13:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
network: add minimal support for InfiniBand (2.71 KB, patch)
2012-12-04 13:56 UTC, Dan Winship
committed Details | Review

Description Matthias Clasen 2012-05-31 01:44:34 UTC
NetworkManager supports bridging nowadays; the network menu should show
something reasonable when it meets such a network configuration. 'Reasonable' might very well be 'just like wired' here.

See http://fedoraproject.org/wiki/Features/NMEnterpriseNetworking

(Note: this bug is part of a series of bugs I'm filing for handling 'exotic'
network constellations)
Comment 1 Dan Winship 2012-08-22 12:34:08 UTC
s/bridging/IPoIB/
Comment 2 Dan Winship 2012-08-27 15:16:27 UTC
The only real question here is whether to mix ethernet and IPoIB devices together, or to have separate "Ethernet" and "IPoIB" sections (see also bug 677151).

Assuming the machine has both ethernet and ipoib (which it probably does, since everything has onboard ethernet these days), then there isn't really even that much difference between the two approaches, since multiple ethernet devices already get split up into separate menu sections anyway. The only difference is that one way the sections would be labelled "Ethernet" and "InfiniBand", and the other way they'd be labelled "Intel 82579LM Gigabit" and "Mellanox Blah Blah Whatever".
Comment 3 Dan Winship 2012-12-04 13:56:43 UTC
Created attachment 230657 [details] [review]
network: add minimal support for InfiniBand

If present, InfiniBand devices show up with the ethernet devices (and
the presence of an InfiniBand connection will cause "Wired" to be
renamed to "Ethernet").
Comment 4 Giovanni Campagna 2012-12-10 22:39:34 UTC
Review of attachment 230657 [details] [review]:

::: js/ui/status/network.js
@@ +630,3 @@
+});
+
+const NMDeviceWired = new Lang.Class({

Can't we have a NMDeviceInfiniband to implement the device specific auto-connection code?
Or is it impossible to add-and-activate an infiniband connection?
Comment 5 Dan Winship 2012-12-11 09:00:42 UTC
In theory NM supports autoconnect of infiniband, but in reality, anyone with an infiniband connection will have configured it at install time.
Comment 6 Giovanni Campagna 2012-12-13 23:58:23 UTC
(In reply to comment #5)
> In theory NM supports autoconnect of infiniband, but in reality, anyone with an
> infiniband connection will have configured it at install time.

A similar theory holds for wired too, yet nm-applet has always included code to add a new connection if needed, and I dragged it into gnome-shell when I wrote the indicator originally.
Should that be removed as well? Will NM ensure that something is always configured for each wired-like device in the system (maybe with autoconnect=false)?
Comment 7 Dan Winship 2012-12-14 12:34:54 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > In theory NM supports autoconnect of infiniband, but in reality, anyone with an
> > infiniband connection will have configured it at install time.
> 
> A similar theory holds for wired too

It's not ethernet vs infiniband, it's server use cases vs desktop use cases. Autoconnect was designed for desktop users, but infiniband only exists on server-class hardware. (And yes, there are enterprise users who run desktop environments on their servers, so putting minimal InfiniBand support into the shell isn't totally pointless.)

At any rate, for an infiniband connection you need to configure whether to use datagram or connected mode anyway (and in the future possibly additional options), so if we wanted to do autoconnect, we'd have to add code to try one, and then if it doesn't work, try the other. (And then no one would ever use the feature because they already configured their infiniband connections at install time.)
Comment 8 Giovanni Campagna 2012-12-14 18:21:01 UTC
Uhm, I see what you mean now, and it's a fine for me.
Consider the patch accepted-commit_now.
Comment 9 Dan Winship 2012-12-17 13:13:52 UTC
Attachment 230657 [details] pushed as 8a1b834 - network: add minimal support for InfiniBand