linux-kernel - Re: infiniband limit of 32 cards per system?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <adaljfko1cm.fsf@roland-alpha.cisco.com>
Date:	Tue, 26 Jan 2010 16:09:13 -0800
From:	Roland Dreier <rdreier@...co.com>
To:	Alex Chiang <achiang@...com>
Cc:	linux-rdma@...r.kernel.org, justin.chen@...com,
	linux-kernel@...r.kernel.org
Subject: Re: infiniband limit of 32 cards per system?


 > It looks like we have a hole from [128, 192).
 > 
 > Would it be something as simple as this?

 > -       IB_UVERBS_BASE_MINOR  = 192,
 > -       IB_UVERBS_MAX_DEVICES = 32
 > +       IB_UVERBS_BASE_MINOR  = 128,
 > +       IB_UVERBS_MAX_DEVICES = 64

I don't think this is a good idea for two reasons:

 - It doesn't take into account the fact that the infiniband_mad and
   infiniband_cm drivers will take up more minors if more devices appear
   (in the best case, you would only be able to run opensm on the first
   32 HCAs or something like that).

 - It changes the minor of the first uverbs device, so something like a
   system with hardcoded static /dev would break in a mysterious way.

I think unfortunately we have to extend the device # assignment so the
first 32 HCAs get the same minors they would have and then overflow into
some dynamic region.

 - R.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/