Re: [PATCH rdma-core] kernel-boot: modules: Load ib_umad for RoCE hardware

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 05, 2018 at 06:34:44PM +0200, Nicolas Morey-Chaisemartin wrote:
> 
> 
> On 04/05/2018 06:05 PM, Jason Gunthorpe wrote:
> > On Thu, Apr 05, 2018 at 05:40:46PM +0200, Nicolas Morey-Chaisemartin wrote:
> >>
> >> On 04/05/2018 05:20 PM, Jason Gunthorpe wrote:
> >>> On Thu, Apr 05, 2018 at 08:35:26AM +0200, Nicolas Morey-Chaisemartin wrote:
> >>>> On 04/05/2018 12:21 AM, Jason Gunthorpe wrote:
> >>>>> Is this just a userspace bug in ibstat or do roce ports actually implement umad?
> >>>>>
> >>>>> Jason
> >>>> It seems like they don't.  It's just ibstat doing a umad_init()
> >>>> before making few calls to umad_get_cas_names() and a few other that
> >>>> seem to work through simple reads in sysfs (not umad related).
> >>>>
> >>>> Not sure what the clean way to fix this is. Removing the call to
> >>>> umad_init feels dirty but it's simple enough.  Any ideas ?
> >>> Maybe we should make umad_init not open the umad device if the link
> >>> layer is ethernet, iwarp, etc?
> >>>
> >>> Hal?
> >>>
> >>> Jason
> >> As there may be multiple device type in the same host, I don't think it'd be that easy.
> >>
> >> Right now the only thing umad_init() is doind is checking version against the kernel ABI (or something like that).
> >> This is not required for a lot of the umad API as they only list stuff in sysfs.
> > It is not umad_init we need to remove, but umad_open_port should not
> > be called if the link layer is ethernet.
> >
> > Jason
> 
> For ibstat, I don't think it is calling umad_open_port.  It's only
> call to umad are umad_init, umad_get_cas_names, umad_get_ca,
> umad_get_ca_portguid and it doesn't seem like any of these call
> umad_open_port.  The failure from ibstat is due to umad_init which
> fails because there is no /sys/class/infiniband_mad/abi_version as
> we only have RoCE hw and the ib_umad module is not automatically
> loaded.

Ooooh I see now.

Yes, this is structured badly.. We should make umad_init into a NOP
and learn the abi_version only when we need it.

How about this?

diff --git a/libibumad/umad.c b/libibumad/umad.c
index dcb2c6809eb12c..08efb089d990cc 100644
--- a/libibumad/umad.c
+++ b/libibumad/umad.c
@@ -90,9 +90,31 @@ static int umaddebug = 0;
 static const char *def_ca_name = "mthca0";
 static int def_ca_port = 1;
 
-static unsigned abi_version;
 static unsigned new_user_mad_api;
 
+static unsigned int get_abi_version(void)
+{
+	static unsigned int abi_version;
+
+	if (abi_version != 0)
+		return abi_version & 0x7FFFFFFF;
+
+	if (sys_read_uint(IB_UMAD_ABI_DIR, IB_UMAD_ABI_FILE, &abi_version) <
+	    0) {
+		IBWARN("can't read ABI version from %s/%s (%m): is ib_umad module loaded?",
+		       IB_UMAD_ABI_DIR, IB_UMAD_ABI_FILE);
+		abi_version = 1 << 31;
+		return 0;
+	}
+
+	if (abi_version < IB_UMAD_ABI_VERSION) {
+		abi_version = 1 << 31;
+		return 0;
+	}
+
+	return abi_version;
+}
+
 /*************************************
  * Port
  */
@@ -502,19 +524,6 @@ static int dev_to_umad_id(const char *dev, unsigned port)
 int umad_init(void)
 {
 	TRACE("umad_init");
-	if (sys_read_uint(IB_UMAD_ABI_DIR, IB_UMAD_ABI_FILE, &abi_version) < 0) {
-		IBWARN
-		    ("can't read ABI version from %s/%s (%m): is ib_umad module loaded?",
-		     IB_UMAD_ABI_DIR, IB_UMAD_ABI_FILE);
-		return -1;
-	}
-	if (abi_version < IB_UMAD_ABI_VERSION) {
-		IBWARN
-		    ("wrong ABI version: %s/%s is %d but library minimal ABI is %d",
-		     IB_UMAD_ABI_DIR, IB_UMAD_ABI_FILE, abi_version,
-		     IB_UMAD_ABI_VERSION);
-		return -1;
-	}
 	return 0;
 }
 
@@ -618,9 +627,13 @@ int umad_open_port(const char *ca_name, int portnum)
 {
 	char dev_file[UMAD_DEV_FILE_SZ];
 	int umad_id, fd;
+	unsigned int abi_version = get_abi_version();
 
 	TRACE("ca %s port %d", ca_name, portnum);
 
+	if (!abi_version)
+		return -EOPNOTSUPP;
+
 	if (!(ca_name = resolve_ca_name(ca_name, &portnum)))
 		return -ENODEV;
 
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux